Test Driven Development. Some people just don't get it.

Some people say: "A test for each feature? But that would mean writing twice as much code!"

These people usually go on to say: "It's just not worth it. I've finished my code, and it works, and you're still writing the test! I leave you in dust, you slow coding type!"

Then again, some people choose platforms, frameworks and even programming languages based on how easy it is to do TDD using them. If they can't do TDD ea sily, they pick something else. They're that committed to it.

The hare starts out faster. The tortoise is much slower out of the gate.

The tortoise knows that the finish line isn't when the code is written, it's when the customer has a working product. The hare might think they've finish ed, so they sit down and have a nap (or to stretch the analogy slightly, get bogged down fixing unnecessary bugs). That's when the tortoise overtakes.

I used to be a hare, running frantically back and forth over the whole codebase, changing things here and there until I thought I was done with a feature . Invariably I wasn't; there were bugs to be fixed and features missed. I thought just because I could write code quickly, I was adding value quickly.

And then I fell in love with TDD. Since I discovered it after reading "Extreme Programming explained" by Kent Beck (buy: uk us), I've not looked back. All o f my clients (like it or not), suddenly got test frameworks for free just so that I could develop using TDD. I rarely do any coding at all in any other way.

Why use TDD? Here are my main reasons:

Refactoring power. If I have a unit test testing each feature of my code module, I can merrily move stuff around internally as much as I like, without worrying if it's broken. At the end, I just run the tests. If it still works, I'm done.

Remembering what you are doing. It's very easy in a large application to get lost on which feature you are currently coding. If you are coding using TDD, then you can't get lost. There's a very simple cycle to follow: Write failing test. Write code so test passes. Refactor if necessary. If you forg et where you are, just run the tests. If they pass, you need to move to a new feature. If they fail, fix them. Simple.

Peace of mind. I've written a large application recently which bills customers weekly for products. When I release a new version of the applica tion, I have to know the billing is going to work. If it doesn't I get in a lot of trouble. Now I know the application is working before I release it , just by running "ant test" and waiting a couple of minutes.

Hares start out faster. But they get complacent, they have a nap, and invariably run into problems in the end. Tortoises get to the finish line first.

If you'd like to know more about TDD, visit these links:

A nice TDD essay, comparing TDD to MDD (model driven development).
A rebuttal of Microsoft's version of TDD, with a very good intro to 'real' TDD, by James Shore.