Along the way almost everyone I talked to understands the basic idea that the earlier in the cycle you find a defect the cheaper and easier it is to fix, and from this most (if not all) agree that Unit Testing is one of the most cost effective ways to catch these defects. The problem is, it appears, developers are lazy; they understand they should do it they just never get around to it – ‘perhaps on the next project’.

As part of my own development I like to work with, be trained by or just hang with people that I see as having reached a higher level of knowledge and skill than me in a particular field. You could say a greater Mastery of the subject. One area that I am very passionate about, many may have seen some great interviews on the subject, is Test Driven Development (TDD). TDD is more than just doing Unit Testing; it is a technique that once you understand and are willing to invest time in helps you to become a better developer.

I have been doing TDD, although not on every project (sadly), for about 2 years and have shared the knowledge I have gained through white papers, blogs and talking at conferences. In trying to lead the way in my area of expertise, SharePoint, I felt that I was missing something. I had yet to reach a place where I felt that I had mastered the art, where I had moved into the phase of challenging myself to do more than just the practice of TDD.

As part of my work with Typemock, the only solution of working with SharePoint’s sealed API, I found that these guys really did get it, they had the battle scars and were practicing what they preached, and they were challenging themselves to do it different, better. Roy Osherove is the Chief Architect at Typemock and I have seen him speak at conferences in a way that was engaging and thought provoking. The opportunity therefore to be able to spend 5 days with Roy doing a TDD Master Class was one that I could not miss.

I’m not going to do the, on day 1 we did this, on day two we did this, as I think that Sara (fellow attendee) has covered this quite well in her post. Instead I will talk about how the course was much more than a lesson in Test Driven Development; we paired up to cover all of the practices looking at the basics of unit testing frameworks (Nunit, MSTest), understanding isolation frameworks (Moq, Rhino Mocks, Typemock Isolator) and how they all look to solve the same issues whilst using slightly different syntax. We looked at how the techniques around TDD have evolved over time, and the how the tools have really moved on significantly in recent years making the barrier to entry and the ability to create readable and maintainable code possible. We looked at techniques, like the daily Kata, that will help perfect the practices, and discussed the ideas of Shu -Ha -Ri where the student moves from the fundamental techniques, to finding new ways and challenging tradition and then onto surpass the teacher and ultimate mastery.

I liked the way Roy questioned the idea that the lazy coder was in fact the one looking to do it as easily as possible, the one who knew all of the keyboard short cuts, the one with all the Live Templates in ReSharper. The Lazy code is really the one who gets the job done well, with the least amount of effort – unlike the average developer, who I initially thought of as lazy, who just doesn’t see development as a craft but more a way to pay the bills.

My view that learning from someone, who is at a higher level of knowledge and understanding has been reaffirmed. The same principles should apply to you, when you look at training and work, ensure that the person teaching you is someone you admire, someone who you feel has the level of knowledge and experience that you aspire to.

Having attended Roy’s TDD Master Class I can say that my knowledge has been enhanced, the core values have been reaffirmed and I am now in a much better place with regards my own capability, but more importantly my own ability to help others.

So the question is should you attend Roy’s TDD Master Class?

If you want to really Master the Art of Test Driven Development then definitely.

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.