For me, TDD is a specification, design and documentation tool. From writing a test alone you can specify what you want, derive an intuitive interface and end up with a snippet of code as an example of how to use it. With this specification in place you also have a goal, the green bar – your tools will tell you when you’re done. And it’s hard to practise TDD without components that are all munged together, so loose coupling tends to appear. The fact that you get unit-tests for free is also a nice bonus which allows daring refactoring.
This is a revelation that crept up on me over time. Like (I’m sure) most developers upon stumbling across test-driven development, I initially fixated on the ‘test’ aspect of it. Its reasonably natural to do so, as everything stems from writing tests, its easy to assume the testing is the most important aspect of TDD. The fact is, test-first is an immensely powerful design tool, that also happens to leave you with loosely coupled, highly tested code. Bonus.
Darren Hobbs 