Test First Development - the 'Killer Feature'

I've been using Unit Testing for some time now and after some protesting I've eventually come round to being something of an advocate of Unit Testing. The thing that finally sold me was the usefulness and productiveness of unit tests when used with a Test-First methodology.

Test-First development itself was born out of the whole Xtreme Programming/Agile programming wave of a few years ago, and basically says that you don't code then test, but write your tests then implement the features needed to make them pass. This to me is a great example of what Agile Programming does best; namely to be practical in approach yet retain empathy with the developer real world situation. So, how does it do that? Well, quite simply developers hate doing tests, sure it's something that most developers will agree is a worthwhile endeavour but even developers who advocate proper testing procedures and QA baulk at actually doing those same tests themselves (can you say NIMBY?); mainly because its tedious, it isn’t any sort of ‘challenge’, I've got a deadline & this won't help me hit it and anyway “shouldn’t we have a tester who does this?”

Now, in test driven development we write the tests up front, before a line of proper code has been written, you might think this is worse but actually writing test frameworks first gives you several real advantages; you to fully understand what you are going to do to implement a feature or a piece of business logic – questions such as: what properties does a class need to expose and what granularity is needed for the methods available to the end user are sometimes only obvious when you actually try and use it from the outside. But the killer feature of testing up front and the one that sells it the test lazy developer is that up front testing adds value to your work; the ability to use those tests to help YOUR work rather than prove that your work is good enough to your 'friendly' QA representative. Test-first leverages the effort invested in tests when you need it most, i.e. when your code is experiencing churn (modifying/adding/refactoring code), and there are few times where code experiences more churn then when it is first being written. The ability to write a method, run the tests and know immediately that your code fulfils it’s requirements (and can handle exceptional circumstances) is a great boost to personal morale & productivity and implicitly leads to good quality code and importantly provides a great way of debugging those issues that do crop up.

It’s nice to see that development tools are finally reflecting the new methodologies that have appeared over the last few years and giving real improvements after a realatively dry spell and (especially in Visual Studio’s case) reliance on improvements in the underlying platform rather than new thinking in the IDE. Thinking of Visual Studio specifically, the 2005 edition’s Team features include a NUnit like testing framework (although as you may imagine it’s more tightly integrated into the IDE than NUnit). This enhanced framework facilitates Test first programming by allowing tests to refer to non-existent member (merely failing the test with a “member not found”), and for that member’s implementation stub to be generated by Studio’s refactor options. It’s just a shame that those features aren’t available in the lower end Studio options (and the new Express editions).