Minimum Possible Client

Interesting conversation on Thursday I overheard at a client site.

Mature Development Manager: Does it pass the unit tests?

Cocky Young Developer: Pardon?

MDM: What unit tests do we have?

CYD: Kim and Chris. <brittle laugh>

MDM: Don’t we have any unit tests?

CYD: It's written in Word so no, unit tests aren’t possible.

MDM: Isn’t most of it in C#? You can unit test that at least. Where is the code in TFS?

CYD: I don’t put it in TFS.

If I had been that developer’s manager, he would have either put the source code in that instant or have been no longer employed.

I looked at my code and the unit test I was just writing. My code is for SharePoint and that is also not easy to test but over the years, I have learnt to keep the linkages to SharePoint very light, e.g., event receivers and feature receivers have no code in them except for a single call into the class that does the actual work and use dependency injection to pass anything environmental, e.g., an SPWeb, so that the functionality can be unit tested.

However, what I was testing was not really unit testable as it had to copy something from one web to another and then call a SharePoint method on it and I wanted to check that it had worked. The problem is that I can’t easily mock up the SPWeb objects. They are just too big and complex and the environment is crucial because it can fail for multiple reasons. Before I have written unit tests that create SPWebs and SPSites, but these are really integration tests. Then I realised that what I needed at that moment was not a unit test, or an integration test because the deployment invoked, via a feature stapler, a feature that called the static method on the static class that invoked the copy functionality and our deployment process requires us to create a series of SPWebs that cover all the possibilities. So it can’t be easily released without being tested. What I needed was a cheap way to invoke the method so I could do ad hoc testing without having to create an SPWeb and easily debug it if it did. What I needed was the Minimum Possible Client for this method and I had such a thing. It was a very simple unit test.

[Fact]
public void DoesChangeThemeInNonRootSiteRootWeb()
{
   using (var rootSite = new SPSite("http://root.local/"))
   using (var rootWeb = rootSite.OpenWeb())
   using (var site = new SPSite("http://root.local/office/london/"))
   using (var web = site.OpenWeb())
{
     // Arrange
     var expectedTheme = rootWeb.GetCurrentTheme();
     // Act
web.ApplyParentTheme();
     // Assert
     var actualTheme = web.GetCurrentTheme();
    Assert.Equal(expectedTheme[Theme.FontSchemeUrlFieldInternalName], 
    actualTheme[Theme.FontSchemeUrlFieldInternalName]);
    Assert.Equal(expectedTheme[Theme.ImageUrlFieldInternalName], 
    actualTheme[Theme.ImageUrlFieldInternalName]);
    Assert.Equal(expectedTheme[Theme.NameFieldInternalName], 
    actualTheme[Theme.NameFieldInternalName]);
    Assert.Equal(expectedTheme[Theme.ThemeUrlFieldInternalName], 
    actualTheme[Theme.ThemeUrlFieldInternalName]);
}
}

Now this does not appear to have dependency injection but the method is actually an extender so we can call anything that implements SPWeb. There is an internal method called ApplyTheme(this SPWeb sourceWeb, SPWeb destinationWeb) which I could have tested instead but I wanted to test the minimum possible and the name of the method ApplyParentTheme makes its purpose obvious. If I was properly testing, I’d have two sets of tests for GetParentWeb() and ApplyTheme() but this is enough because of the deployment tests.

It turns out Unit tests make excellent Minimum Possible Clients.

And yes, dear listener, all of my code lives in TFS.

Cheers!

Filed under: CodeProject