For almost my entire career I have been involved in software development, and probably uniquely more often than not in an environment or role where I have needed to look at process improvement. This started with my first role where I had to ensure development adhered to ISO9001 standards, through to today where I work with teams to help them adopt agile techniques and continuous improvement.

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.