The Moles Framework: SharePoint Unit testing best practices

[What you have]:

You have a SharePoint 2010 application

[What you want]:

You want to automate the testing process for the SharePoint application.

[What you want to know]:

Here is a quick summary of the different types of testings:

Unit Testing - an automated procedure to test a single aspect of the code. It doesn't contain logic branching. The unit test is typically written against public methods and interfaces.

Integration Testing -  verifies the functionality against a target system/platform. For an example, web services, security, stress testing.

Continuous Integration Testing (CI) -   a process that provides a continual verification of code as it is checked into the source repository. To implement such testing  use the Team Foundation Build.

Web Testing - (aka "UI test") -sends HTTP requests and verifies the HTTP response.

Stress Testing -  the purpose of a stress test is to drive the component beyond its normal operating conditions to ensue that it degrades gracefully.

Functional Testing -  any procedure that tests the end-user functionality.

Build Verification Testing (BVTs) - similar to CI but used to determine whether code meets the end-user functionality requirements.


Load and Scale Testing -  The idea is to ensure that the system behaves well under normal high-end load conditions and to understand how an application scales as load increase.

User Acceptance Testing (UAT) -  testing the system from user's perspective. Functional testing by business owners is considered to be a part of UAT.


The most common testings are Unit, CI, UAT.

This post focuses on the Best Practices "SharePoint Unit Testing".

Aim to decouple the code from UI. To make the Unit Testing in SharePoint application possible:

- Use MVP pattern to isolate business logic from the UI and the data source.
- Implement interfaces for your view classes\services.
- Use the Service Locator pattern to decouple a presenter class from specific implementations of the class that the presenter uses.

To remove the uncertainty the dependency classes should be replaced with fake implementations.
These fake implementations are known as fakes, mocks and stub.

Using fake classes is straightforward if you fake the class that is been created by yourself and you have control over how the class is implemented. It can be more challenging if you need to provide substitutes for external classes.

Most  SharePoint objects don't implement interfaces\virtual methods, are sealed with private constructors. This fact makes the "faking" of SharePoint object impossible.

In this case a detouring framework should be engaged.

The Moles Framework provides ability to test SharePoint object via a detouring capabilites.
The Moles is a Visual Studio Power tool - free to download. The moles has 2 kind of classes: Stub and Mole types.
 
Use stubs for your own code and third-party code that exposes virtual methods\interfaces that you are able to override. In other cases, use the mole type. The mole intercepts calls to dependency classes and redirect the calls to a fake object.

 Test a single behavior in one unit test. If you have branching logic in the unit test, that means you should have split the logic into several unit tests.

Use Arrange Act Assert pattern in the unit test.

Prefer  Behaved types over conventional mock and stubs.

[What you want to consider]:   

Take a look at the real-world example of using Unit tests for SharePoint 2010 - Developing Applications for SharePoint 2010 (downloads) 

 A free addition to the book Designing Solutions for Microsoft SharePoint 2010: Making the right architecture and implementation decisions (Patterns & Practices) - bibliography - Chapter 11 will explain in the greater details how to implement unit testing in the SharePoint application

Or, buy the source of this post - Designing Solutions for Microsoft SharePoint 2010: Making the right architecture and implementation decisions (Patterns & Practices)