TDD in SharePoint Using DI – Summary
This post is part of a series on Test Driven Development – Using Dependency Injection
In this 5 part series we refactored the solution developed in our white paper Unit Testing SharePoint – Getting into the Object Model to make the code more testable, and enable us to work within the available features of TypeMock Isolator for SharePoint.
We started with a review of the code and the specific line of test code that was not supported, reviewed the options available to us including upgrading to the Full version of TypeMock but decided to refactor the code and introduce a pattern called Dependency Injection.
Before digging into the code we introduced some of the common TDD vocabulary including Loosely Coupled, Dependency Inversion, Dependency Injection and Inversion of Control. The aim not being to scare people off with fancy terms but to help understand what these mean and the affect they have on your code.
The refactoring of the code began in Step 1. where we started to implement Dependency Inversion to give more control to our calling code, in this case our tests. We introduced abstract classes and the use of an Interface to support this.
Step 2 Implemented dependency into the GetRandomMessage method and also the concept of creating Fake classes that can be passed in to support the tests we wish to perform. At the end of this step we were able to refactor our initial failing test and all the tests passed.
The code for this refactor can be downloaded from here.
This blog series proved a valid exercise in refactoring existing code to make it more testable and also demonstrated that the reduced features of Isolator for SharePoint, at a reduced price point, do allow you to do TDD in SharePoint.
Whats next?
Andrew Woodward, follow him on twitter, will be speaking at the Best Practices SharePoint Conference in San Diego on in Feb 2009 looking at agile SharePoint development with Scrum and Test Driven SharePoint Development.
