This project is read-only.

Project Description

FakePoint is a set of fake (mock or stub) SharePoint object model API classes to enable unit testing and TDD. The FakePoint DLL is referenced in the test project in place of the SharePoint assembly, allowing the fake API classes to be used transparently without special coding.

The Problem

Unit testing is very difficult with SharePoint. Much SharePoint development is involved with the user interface, which is notoriously difficult to unit test. But an even worse problem is that the SharePoint object model API is large and complex, and interactions with SharePoint objects often comprise the majority of the coding in a SharePoint development project.

The common solutions are either to use a mocking framework, or to radically modify the solution architecture to create an abstraction layer around SharePoint. Currently the only framework that can be used to emulate the SharePoint API is TypeMock Isolator, which is excellent, but is a commercial product. The architectural wrapping approach usually results in a complex dependency injection pattern, or in unit tests that are "protected" from the critical sections of code.

Unit testing is so difficult that in many SharePoint development projects the developers are obliged to go straight to integration style testing against a local instance of SharePoint. This introduces enormous configuration dependencies into the tests, and makes the test cycle slow enough to hamper development and debugging and prevents the adoption of test-driven development (TDD).

How FakePoint can help

FakePoint gives you an alternative to mocking and re-architecting that allows you to replace the SharePoint API with a set of fake classes. Rather than setting up a response for each API call prior to running the test, an entire fake SharePoint site is created, complete with content. Once this fake site is set up, any number of tests can be run against it. This makes test setup very simple and also removes the need to predict what the API response would be to a particular call in order to set up the response conditions.

How FakePoint Works

FakePoint uses a CAML (Collaborative Application Markup Language) XML representation of the test site. Usually you will have already created a test site in SharePoint, so you can obtain the CAML representation of the site by creating a site template, using SharePoint Designer or using SPExplorer to capture a test site. The CAML is also the same XML format used to provision sites or parts of sites in creating solution packages. You could also of course create or modify this file by editing the XML directly. Once created the CAML file will need to be added to source control. SharePoint does not need to be installed to run the tests.

In your SharePoint solution you will create an MSTEST test project. This project will reference the FakePoint DLL in place of the normal SharePoint assembly. It will also contain links to the source files of your project so that the test project will be a separate build, rather than referencing the output of your production project. When FakePoint it is initialised the CAML file is loaded into an XMLDocument. The FakePoint assembly contains fake classes such as SPWeb and SPList in the Microsoft.SharePoint namespace. As your application code, under test, navigates around the SharePoint object model, these fake classs are instantiated as required and wrap the various nodes in the XML DOM tree.

FakePoint can also be used with other test frameworks such as NUnit. In this case you will still need to create a separate project in Visual Studio so that it can be built with the FakePoint DLL in place of the normal SharePoint assembly. Obviously, due to namespace conflicts, the FakePoint assembly cannot coexist with the actual SharePoint assemblies.

Limitations (before we get too excited)

Currently FakePoint only covers a small proportion of the SharePoint object model. However, this is sufficient to facilitate some of the most common scenarios, particularly when building web parts. At this stage we do suggest that the project should be considered as a work-in-progress. Please view it as a starting point for building your own fake SharePoint API covering the areas of particular interest to you, rather than as a complete and faithful emulation of the SharePoint API. If you do extend the coverage, please will you to feed those improvements back into the project?

Last edited Mar 9, 2010 at 3:50 PM by flosim, version 17