Quality is free, but only to those who are willing to pay heavily for it.
— Tom DeMarco and Timothy Lister Peopleware: Productive Projects and Teams
Test-driven development (TDD): to some it’s a religion. To some, it’s the only sane way to develop code. To some, it’s a nice idea that they can’t quite make work. And to others, it’s a pure waste of effort.
What is it, really?
TDD is an important technique for building better software, although there is still confusion over what it means to be test driven, and over what a unit test really is. Let’s break through this and discover a healthy approach to developer testing, so we can write better code.
It’s a no-brainer: we have to test our code.
Of course you run your new program to see whether it works. Few programmers are confident enough, or arrogant enough, to write code and release it without trying it out somehow. When you do see corners cut, the code rarely works the first time: problems are found, either by QA, or—worse—when a customer uses it.
To develop great software, and develop it well, programmers need feedback. We need to receive feedback as frequently and as quickly as possible. Good testing strategies shorten the feedback loop, so we can work most effectively: