Applying DDD, TDD and Patterns to enable Reuse your SharePoint Code
John W Powell has posted a great article on MSDN where he explains how he used Domain Driven Design (DDD), Test Driven Development (TDD) and design Patterns to create a framework for working with the SharePoint.
He goes into detail about the framework and the reasons for the final design. I would have liked to have a little more detail, code samples, from the iterations he went through to reach this design to help people better understand how the DDD and TDD are really about designing better software. He does say himself, so I can’t really complain
Now I’m pulling a “Julia Childs” on you. I already went through several iterations of TDD and refactoring to arrive at the implementation…
It’s really encouraging to see more of this information being published that demonstrates it is possible to do good design in SharePoint projects using agile techniques.
I have a few small areas that I disagree with, first the approach taken seems to be more test-after, in the SharePointListRepository example early on he states that “Following TDD, we’ll create a unit test that will fail until we implement the repository”. I have no issue with the writing of tests that fail and making them pass but TDD is about driving the design and John had already made the design choice before he implemented the test. To be fair to John this may be more about the way he wrote the blog than the code.
The Second I may being ultra critical about the naming of the tests, but he has two tests both named GetListsTest this makes it harder to understand where a test is failing.
Personally I like to adopt a naming convention that defined exactly what is being tested and the expected results, something like:
SharePointListsServiceGateway_GetLists_ReturnList
If your getting into Behaviour Driven Development (BDD) then the naming of tests takes on an even more meaningful role.
The third and more important is the use of ‘var’ in the tests for the SharePointServiceUrl. If you look at the tests GetServiceUriTest and GetServiceUrlEndsWithSlashTest the tests are identical, my feeling is that with the test GetServiceUriTest John was aiming to test the overloaded GetLists method that returns a Uri. However the use of ‘var’ means that Visual Studio and the compiler make the call that this is actually a call to the method that returns a string. If you isolate the tests in this method only you will see that this code is not called, the full code coverage however it shows 100% coverage as another test is exercising this code – a warning that just because you have 100% code coverage doesn’t mean you’ve tested your code.
The forth and last observation is probably the most important. The tests created are Unit Tests, although if is often debated what a Unit is, one things that a Unit Test should not be is an Integration Test – however the GetLists tests have a dependency on SharePoint. If your environment does not have a SharePoint web application matching http://contoso.com/ these tests will fail.
I have probably been too hard on John here as the emphasis of the post was about the framework, it would however be good to make the reader aware of these and the reason for skipping them. With that said I am still made up that people are starting to put stuff out there to help us all improve the way we develop.
Way to go John!.
PS: John was happy for me to post the comments as he wants to spark the conversations.
