November 14, 2007

...Learn TDD with Codemanship

Test-driven Development Is Not About Testing

The fact that I'm flying to the Canary Islands for my winter holiday is not the point of the holiday. I don't love to fly, and would prefer to just sort of mysteriously "arrive" at my destination, ideally with a nice cold glass of Chardonnay in my hand.

Unfortunately, there is the small matter of physical distance to be overcome. So I have to sit on a plane for four hours while about a thousand miles of fresh air whizzes by me.

But I consider myself a holiday maker, not a passenger. The flight is not the point of the holiday. It is a means to an end.

And someone who does test-driven development is not a tester. The tests are not the point. They are a means to an end.

The end of TDD is well-designed, working code. In TDD, we use tests to specify what code we should write. The fact that we can run these executable specifications and get immediate feedback that our code works is a bonus, and a big one, but it is not the purpose of TDD. It is a very useful side effect.

People who practice test-driven development are doing design. It's important - actually, it's critical - to understand that. If you fall into the trap of thinking that TDD is about unit testing, then you'll probably miss the point.

Too many teams believe they're doing TDD, but are actually just writing unit tests for code they've already written, or writing one unit test and then writing 500 lines of production code before they move on to the next unit test.

Recently, people have attempted to make the distinction clearer, taking the "T" word out of the title and referring to behaviour-driven development or example-driven development or scenario-driven development: just so everybody knows that we are not talking about testing.
Posted 2 weeks, 5 days ago on November 14, 2007