Unit Testing in SharePoint

The SharePoint development ethos is fundamentally about composition. The building blocks are small general purpose self-contained components, which only come to life as a full application when they are combined and interconnected along with content, often by a content editor or designer. The key to successful SharePoint development is to build simple, reliable components, but with a clear vision of how they will be combined to create sophisticated web applications. This is particularly the case for development of public-facing Internet sites. These simple components are most commonly:
  • Web parts
  • Deployment components (e.g. feature receivers, a solution packages)
  • Utilities to transform content

And here lies the problem; because in general these web parts and other components will be very simple in nature, which makes it difficult to justify building a complex architecture just to achieve automated unit tests. In a large and sophisticated line-of-business application an extravagant adventure into exotic software design patterns is easily absorbed within the overall grand design, for the architecture is already complex. But in the context of such a simple component as a web part, such complexities as dependency injection and inversion of control containers begin to look embarrassingly like overkill.

The fact is that automated unit testing is not easy to achieve in SharePoint development. For one thing, user interfaces are notoriously difficult to test in themselves, and that is what we are effectively producing in a web part. That would be bad enough but in addition the generation of the content for that user interface will rely heavily on the SharePoint object model which brings problems of its own. This is because of the large number of sealed classes, classes with dependencies and without a public constructor. These obstacles frustrate all but the most powerful mocking frameworks (the only option at the time of writing is TypeMock Isolator, which is a commercial product). In addition the use of mocking requires that the subtleties of behaviour of the SharePoint API can be predicted when setting up the return behaviour of the mocks.

An alternative is to wrap the API in either general purpose or business object classes to encapsulate the SharePoint API, and mock these wrapper objects instead. The problem here is that, apart from the additional layers of complexity, these wrappers actually insulate the unit tests from the critical code. There is a danger of arriving at a situation where there are elaborate tests for trivial code that is obviously correct and unlikely to change, while all the problematic code hides beneath an abstraction layer.

Many people have concluded that these difficulties mean that unit testing in SharePoint development is not worth the effort, and fear that the amount of code actually being tested ends up being dwarfed by the volume of the test code itself. This is a shame, because automated unit testing is very important to enable efficient development to a professional standard. It is also essential if test-driven development is to be an option.

Last edited Jan 11, 2010 at 3:59 PM by flosim, version 1


No comments yet.