Alan Francis recently posted an inciteful mini-rant about the in-vogue practice of saying that Test Driven Development isn't about testing, but something else (e.g. design, behaviour, specification, etc).

Alan is right, but:

1) I know why people say it isn't 2) Most of those people know that it is about Testing 3) I have often said it too

So, as a follow-on to Alan's comment, I thought I'd explain why:

Its because Testing as generally understood in the world of software development inherently includes the idea of "Performed After Development." In practice its actually easier to present the concept of TDD as something other than testing than it is to change people's definition of testing to exclude "After."

I don't think its a cooincidence that this bit of information was lost-in-translation when "Test-First Programming" + "Refactoring" became TDD -- because right around that time it became a heck of a lot easier to sell to others.

Now that I am no longer in the business of trying to sell Agile, I can both appreciate why people want to exclude Testing from the definition, why Alan thinks its Bullocks -- and why people keep looking for silver bullets, and not finding them (but saying "it's just another refrain of the never-ending song of life "sounds sorta wishy-washy and mystical so I'll just leave as an exercise to the reader).

In short, yes TDD is a technique where, in the course of your daily code production you write a short test, enough code to make that test pass, refactor your code, and repeat.

But! What they don't tell you is: Its hard to use productively. It requires you learn some new things. It requires you to unlearn things that probably work pretty well for you right now. It requires that you understand what makes for good design. It requires you to know the difference between refactoring and simply changing stuff. It takes a long time to get good enough at it that you can be more productive than without it. Once you reach that point, its likely that you won't go back. It will take even longer before you realize its just a tool. Its much easier to learn when programming for many consecutive days alongside someone who can already do it. Its hard to do if you work closely with people who don't want to do it.

Thems the Breaks. Building software professionaly that can be maintained and extended indefinitely, yet still ships on time to customer satisfaction, and satisfies your own need for doing good work is really f'ing hard (you can spend a lifetime just learning how to breath for goodness sake) -- anyone who tells you different is selling something (that doesn't mean you shouldn't listen).

Ahh well. Being is so much less stressful than appearing.

I think I'll try to write one more test (that's test-first shorthand speak for: write a little bit more code, and clean up the design a little bit before calling it a night). Thanks for reading.