Call for common code – Can we unit test it
One of the challenges with unit testing SharePoint projects is the need to fake the calls into SharePoint. If you are a regular reader of my blog you will have seen examples of how I have been doing this using Typemock Isolator.
Microsoft have their own isolation framework called moles. A more accurate descripition would be isolation through detours and stubs. Moles was developed to support Pex white box testing and one interesting development from within the team has been Behaviours. Behaviours are really a way to model the thing you want to isolate for the test without needing to define every isolation point.
Isolatation frameworks (regardless of technology) can result in brittle code, test code that is very tightly linked to the production code. A simple change from List.GetItems() to List.Items[""] will cause the test to fail.
One of the samples provided with Pex is the modelling of SharePoint Behaviour that will make it much easier for people to be able to create robust tests with minimal or no additional isolation code needed. Part of the work we are doing is to drive out the things that need to be modelled and reporting these to the Pex team. It is not going to be easy to model the whole of SharePoint from day one, however it should be possible to cover the areas most used.
This is where I would like some help. Do you have any code that you use often, code that you would like to unit test that takes a long time to isolate and that end up being brittle?
Please post examples here in the comments and we will try to get as much covered as possible.
