Test-Driven vs Test-First
February 28, 2021
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.
TDD only makes sense if you already know the outcome... or does it?
If you don't know what your code should be doing, you have no business writing any code anyway!
The affect of comments in unclear code
Roses are red, violets are blue. Honey is sweet, and clear code is, too.
Help wanted naming this code
Do you have a helpers or utils class or directory in your project? Maybe both? Quit it!