I have observed a lot of confusion out there about the term Test-Driven Development (or TDD). Let me demonstrate with a paraphrased comment from a former colleague:

I tried Test-Driven Development once, and it was a disaster, and a huge waste of time. I spent a week writing all the test cases, then when I got to writing the code, I realized most of my test cases weren’t right, and had to be rewritten anyway. And such an approach only works on a project where the end result is fully known at the outset!

What this colleague was describing certainly is an example of Test-First Development. But it is unequivocally not Test-Driven Development.

When doing proper TDD, your tests drive the development process, in a way similar to driving a car. That is to say, it’s an interactive process. To stretch the analogy to the point of breaking, my colleague’s approach was treating tests like a detailed trip plan.

True Test-Driven Development takes place in very short cycles. 10-15 second cycles between writing a test and writing code is common. A few, single-digit minutes is the maximum. If you spend a week, a day, an hour, or even 10 minutes, writing a test before writing code, you’re doing TDD wrong.