Why Test?

All of the great programmers I know design their applications using Test Driven Development. Most of the other programmers I know have plenty of excuses why they don't (myself included). What's so great about Unit Testing and what are the benefits of TDD that make it so ubiquitous amongst the smartest programmers?

Firstly, unit testing. I find that if I don't write unit tests, as my application starts to get to a certain size, I lose trust in the code. In a complex end-client application I end up with areas of "don't go there" code which I don't want to touch as I know it works, but I'm not quite sure what would break if I change it. In my in-house framework and generation code I find that I have really cool automated code for speeding up tasks, but I often don't trust the corners and the edges of the automated code that I seldom use so if I run into a problem with them I just hack together a custom method rather than taking the time to make my core code more solid (as I'm usually on a deadline and it's almost always expressed in hours or minutes - not days or weeks). I'd really like to be able to build larger applications with confidence, but to do so I need to take the time to build it with components where I've worked through all of the corner and edge cases I can think of and have created an automated test suite so whenever I refactor my code I can see immediately whether it has broken any of the "contracts" that I depend upon in terms of my expected behavior for the code.

Unit tests can also be a great source of agile documentation. They are agile because they are very DRY - you are writing an executable test and just naming it appropriately to make clear the behavior that the test is checking for (and hence the behavior that your class supports assuming that the test is passing). There is no worry of the documentation getting out of synch with the code because if it does, the tests will stop passing and you'll have to rewrite them to express your new intent. And if you take a test driven approach to development, you'll have documentation of the intent of your new class files just before you code them.

Test Driven Development has some more subtle, but more profound benefits. With TDD, you write a test and then the simplest possible code to make that work - adding additional tests and the simplest code required to make those work until your tests cover all of the functions that your class files need to perform. After writing passing code for each test there is a "refactor" step where you clean up the implementation of the code (including the test code) to make it DRY'er and more maintainable hence the common "Red-Green-Refactor" description of TDD (write a failing test, write the simplest code required to pass the test, then refactor the code). It's important to realize that TDD isn't about testing. It is a different way of designing the details of an application. Not using TDD, I've noticed that it is often easy to write over complicated code or even to get stuck in "analysis paralysis" - trying to figure out how to write the one true API that will forever meet your applications needs! With TDD you work iteratively by adding a new requirement (a test) and then simply writing the simplest code that will pass that test. I'm looking forward to trying it on a real project as I've heard pretty much nothing but good things about the experience.

Stay tuned for more postings!