Unit Testing and SharePoint Development

Question

I am interested in writing unit tests for the SharePoint development work I am doing. Can anyone suggest practical approachs to implementing unit tests in MOSS?

Note that any third party tools have to be free (but not necessarily open-source); the company I work for will not pay for additional tooling. In particular, any alternatives to the Typemock Isolator for SharePoint would be appreciated.

Thanks, MagicAndi.

Answer 1

A controversial alternative for you - don't use mocks!

Instead do integration testing because really as soon as you are using the SharePoint OM that is what you are doing.

Put as much of your logic in library assemblies that can run from outside a request Context (overload constructor to pass in either HttpContext or SPWeb).

Setup a server/site (VM preferably so you can rollback and make new instances easily) just for unit tests and run against this. (VMWare Server is free)

If you running continuous build you should be able to set it to run automagically and report results. Alternatively some batch file magic with the open source nUnit or your tool of choice to run the tests as soon as a new .dll is copied over on a PostBuild step.

The disadvantages

• You've got a bit of work setting up data for your tests (though is it much more than getting mocks working?)

• Not everything can be tested like this

• May take a little longer to run, but if running as part of a continuous build is that a problem?

• More discipline needed in a team to avoid stepping on other peoples toes.

The advantages

• Your testing against the real SharePoint OM with all its baffling inconsistencies and special cases (if you were being unkind you may call them bugs ;)

• Who knows what parts of the OM behaviour could subtly change when new service packs / cumulative updates come along, this should help catch any breaking changes.

• When SharePoint 2010 comes along you will be able to run your tests against both 2007 and 2010, see what changed, make sure your library works against both versions (if appropriate to your project)

The trade-offs for all projects are different, but for my projects I prefer the security of knowing I am testing against the real thing - call me old fashioned if you will!