The Problem With Test-Driven Development

Working backwards is just the beginning.

Chris Fox
Chris Fox
May 16 · 3 min read

It’s actually elementary.

I do more upfront design than anyone I know; as a freelancer, I will turn down a client who wants me to work without a spec. At many companies, I’ve written the first design document in their history, and not all of them were startups.

And even with all this planning, it takes me less than a day into coding before I run into some consideration the design docs, mine or not, overlooked.

So writing the tests before the code, the foundation of TDD, guarantees that I will constantly be revisiting the tests to integrate the discoveries I’ve made in coding.

OK, this is inefficient. It’s not catastrophic but it’s just another case of making what is obviously the wrong choice. Nothing at all unusual in our industry.

But what I really dislike about TDD is the intensity of fanaticism around it. In these pages, I’ve seen statements that

  • all software development uses TDD because if it isn’t TDD then it isn’t software development.
  • any unit testing that doesn’t test every line of code is a “dereliction of duty.” The military tone here is seriously disturbing.
  • unit tests are more important than code. If time constraints (imposed by bad managers) require cutting corners, cut them in the code, not the tests.
  • We don’t need design documents anymore. The unit test (singular) serves as a spec. Besides, kids don’t like to read.

I’m a developer since the late 80s, I know what were seeing … today’s young developers have never learned to concentrate and if they can then it’s beaten out of them with constant interruptions, mostly pointless recurring meetings. People who can’t concentrate write shit code with lots of bugs, small wonder they think testing is so important.

And the rationale for TDD is based on lies and myths.

  • Metrics of its value are based on comparisons to no testing, not comparisons to traditional blackbox testing.
  • There is a lie that before TDD we didn’t do any testing at all. That’s bullshit. Anyone who handed his work over to QA only to have them find bugs in ten minutes had egg on his face. We did a lot of testing.

For my money TDD is just another stupid fad, like agile and scrum, though not as directly destructive as Xtreme, which has put people in therapy or even hospitals, and it’s one of a class of software fads where a standard practice is reversed and turned upside down in what is supposed to be some kind of advance. What the hell was the reason for( this )shit?

But the worst part of TDD is the expectation that developers will be primarily if not solely responsible for testing their own work. As if they will think of cases in the tests they overlooked in the code. This is just a jaw-dropping stupid idea.



Everything connected with Tech & Code

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store