Two guys who can talk on a subject they love equals one Podcast gem.

Recently, in a role reversal,  Lukas Svobda host of NZ Arcast shoved a microphone under Ron Jacobs (hoster of worldwide Arcast) nose and they discussed mainly Test Driven development (TDD). Both of these guys are friends of mine and take it from me they can both talk up a storm but interestingly between them they have produced a podcast here that sums up years of experience on TDD and is an absolute gem. It lasts 33 minutes and contains some interesting and relevant material on not only the theory of TDD but also how it can be a powerful tool for architects as well as developers and testers.

What I like about this Podcast

-          The link between TDD and Continuous integration;

-          Why code quality is strongly linked with TDD – it is much easier and far less risky to refractor ‘manky’ code working in an environment where TDD is practised;

-          Design large (architecture) versus Design small (coding) and how TDD can link them (interesting question posed by Ron – should architects write tests ? );

-          Time invested in TDD pays a definite return , reduces time and cost over the code life whilst increasing quality;

Some observations of my own.

I have used TDD on a number of occasions back in the days when I used to cut a lot of code. A couple of things I learnt which Ron and Lukas would not have had time to cover are;

-          Run the tests when you check something out – there is nothing worse than breaking the code and then discovering later (after a lot of mucking about) that it was broken long before it got to you. Of course if you are using Team system you can reduce the risk of this happening by using appropriate check in policies and incorporating base tests as part of your build;

-          Test for exceptions (failures) – a lot of the time code will attempt to manage exceptions and things like escalation and error codes are essential pre-requisite disciplines to have in these situations. Force exception conditions and make sure they return the appropriate ‘error code’ at the right time and in the right place;

TDD is not just about unit testing and the ROI can be maximised by automation

Recently I’ve been talking a lot with Doug Taylor the Chief architect for Provoke – Doug is using VSTS 2008 Test edition to amongst other things load and performance test web sites they are developing using MOSS and ASP.NET.  As a team they have deliberately leveraged their testing approaches and tools with the goal of gaining a reputation for producing functional and reliable web sites (both intranet and internet). In my experience teams that stick with these disciplines over time succeed in achieving such goals and generate a lot of additional business for their owners. There is definite return on investment (ROI) on testing and quality focus and one way to maximise that ROI is to automate testing as much as possible and not just at the ‘unit test’ level.

One clear message I have for anyone looking to implement such strategies themselves is that ensuring TDD is the norm and that automation is both acceptable and supported is just that - a strategy and as such requires buy in from managment, architects, developers and testers.