It all comes down to ones and zeros

For some time now I've been wanting to try my hand in unit-testing, but as I'm primarily working on Sharepoint projects I’ve not had the guts to try decoupling and mocking those pesky API bits. Last week thou I finally worked up the courage to give it a go.


When I set out, my sole experience with unit-testing was a former co-worker of mine giving an in-house talk about the subject about a year ago. So this blog entry will obviously not contain any groundbreaking tips and tricks in that field. But I do think I can help some of those, starting to unit-test Sharepoint, a quick push in the right direction.

As I started, I determined that I would try to get decent code coverage on one simple web-part project that I had recently done, and I picked one that would test out some of the trickier bits to mock and decouple. A workmate who had tried his hand at this before pointed me in the direction of TypeMock as a mocking tool, and I decided to try using the integrated Test-Project template in Visual Studio 2008. That last bit was my first fail of quite a few in this project. Little did I know that mstest.exe, the file used to run Visual Studios tests, was made in 32-bit and 32-bit only. Being a happy camper that day I set my test project to “x64” instead of “Any CPU” as by default, after getting quite a few errors and having to resort to good old Google for answers. That landed got me on the right track again. Enter NUnit…..

My final solution was to use the combination of NUnit, TypeMock and NCover. I’m sure there are other options that are equally good, but my choice fell on these three.

Dropping the test-project that I had added to my solution using the Test-Project template from Visual Studio, I proceeded to add a standard Class-Library project, including the NUnit framework and the project under test as references. All that was left of the setup-process was to set the test-project as startup-project and setting NUnit as “Start external program” under the Debug tab under project properties, with the test-projects assembly as an argument.

Now when I run the debugging by pressing “F5”, NUnit pops up and if I set breakpoint in the test code, I’m able to step through the running of the tests.

Now that I had the environment set up as good as I could, I went about the first order of business, writing tests. I had already done some ground-work by using MVC pattern for the webpart, dividing the code into view, logic and data layers. My first obstacle was getting around the “SPContext” object.

Several places in the code I had used this to get either the webID, or the username of current user and things like that. When running my tests I needed to get a around this object being missing. That’s where TypeMock comes into the picture. I simply used the Isolate.WhenCalled().WillReturn() method.

If I needed the context of my SharepointTest-instance. I could simply create a new SPSite object using the new SPSite(“localhost url”). And use the line:

“Isolate.WhenCalled( () => SPContext.Current).WillRetun(‘the context I had created’);”

Next in line was the SPSecurity object and code that ran with elevated privileges. Here I found a rather great blog entry from a blog named “If you build it, They will come”.

Using the TypeMock Mockmanager and mocking the RunWithElevatedPrivileges-method, we can extract the delegate and invoke it. Quite clever, I would never have come up with something like that by myself.

This was my first Blogpost and I hope that someone saves some time by reading it. I’ll try to post more as I discover more and learn more.

ZiGGstern