TDD, do we really have to do it?
Many really smart people tell us we have to use TDD if we want to create code that is worth a penny. For example take this article about TDD by Uncle Bob (one of the moderate ones). He describes the benefits of TDD in paragraphs like this:
If all your code works every minute, how often will you use a debugger? Answer, not very often. It’s easier to simply hit Ctrl-Z a bunch of times to get the code back to a working state, and then try to write the last minutes worth again. And if you aren’t debugging very much, how much time will you be saving? How much time do you spend debugging now? How much time do you spend fixing bugs once you’ve debugged them? What if you could decrease that time by a significant fraction?
But the one thing he does not provide is anything close to a proof. He offers his own experience, which might be distorted for all kinds of things.
Yet with a practice so simple (note: I didn’t write easy) as TDD and so many people advocating it one would like to see some proof of the benefits of TDD. After writing a little piece about opportunities for more research in software development I was recommended this the book: Making Software: What Really Works, and Why We Believe It. It is highly recommended for anybody interested in what works and what doesn’t work in software development. Just be warned it is a little harder to read than Harry Potter
There actually is a chapter about TDD in it. The result: Not a clear win. I’m not even trying to put the details in here, but the result is basically: Although they tried they couldn’t prove TDD to be as effective as many people claimed. But they also showed it is not as costly as many people claimed. And I think they mist at least one point: TDD can teach you a lot about software development and software design on the micro level.
So what is the answer to the question in the title: Do we have to do TDD?
Nope, don’t think so. There are alternatives, like writing your tests after the code. But I recommend TDD to everybody to try it at least for some time. Its a great chance to learn a lot.






You are hitting the weak spot. That is great. But this can be dangerous: Many developers I know have a repulsive attitude towards testing in general and especially TDD.
If I didn’t know you personally it would be hard for me to not take you as one of them. You recommend the technique at the end. It is easy to overlook, although you write clearly that you advise people to try it.
To the 2nd part of the title: “do we really have to do it?” – Of course not. Nobody has to do anything! – What we all have to do is to consciously reflect our work, their results and the techniques we are working with. Then identify potentials to improve.
TDD is it worth it? – Everybody has to decide herself. To me the big big advantage is the influence on design it produces indirectly: Small units of separated code, each with it’s own responsibilities. Additionally explained and “verified” by tests. I have a guarantee of the behavior of the unit. – I like the results of good TDD. If I can get them with other approaches I am also happy.
Hi Andreas,
thanks for the comment, maybe your comment prevents some unsolicited flames.
On the other hand: There is nothing like a nice flame war on reddit for driving traffic to your site.
I think that TDD is a valuable tool to have in the toolbox. It lets you explore the design by writing tests as if you were a consumer of the interface (the clue’s in the name).
However, it’s not a panacea. There are some situations where I’ve found that it’s not a great fit. In those situations, just go ahead and write the code, being mindful of good techniques.
You’ll go back later and, either because you’re finding it hard to add unit tests, or because you notice code smells, you’ll have to do some refactoring. This is valid too.
Like I say: it’s another tool in the box, and it is a good tool. Use it when appropriate, but don’t marry it.
[...] TDD, do we really have to do it? Written by: Jens Schauder [...]