Is TDD doing a lot of harm to the software industry?

I recently spoke with two brilliant developers who were proudly discussing their contributions to the same promising project. Their tone and pride suddenly dropped when I mentioned my obsession with writing tests and the unparalleled confidence that test suites give me when I want to deploy regularly and embark on major refactoring projects.

And then the drama began — they hadn’t written any tests for this project. The discomfort and nervousness that set in during the conversation made me guess that they simply don’t know how to write tests. One of them even dared to tell me that his strictness about types in TypeScript is his way of compensating for testing!

After the conversation, I then wondered how such good developers, capable of switching languages and paradigms, of regularly learning new libraries, and of solving incredibly complex problems, could be unable to write simple, repetitive expectations.

Are We Teaching Developers to Code in the Wrong Order?

I then wondered if the problem might simply stem from the fact that they are being asked to code in the wrong order.

The concepts of TDD and BDD have so thoroughly dominated the world of testing that many developers believe they are incapable of delivering good code accompanied by quality tests without writing the tests first.

Every beginner developer instinctively starts by writing a line of code and executing it, seeing an error message, and changing the code until it works. When the beginner gains confidence and can accomplish less simple tasks, they enter a phase of creative experimentation that is completely incompatible with the rigor of TDD: they need to build-build-build and revel in the joy of achieving things and climbing the Dunning-Kruger hill of stupidity!

Embracing Test-Last Development

These habits then become ingrained over time, and changing them becomes difficult. TDD/BDD advocates will say that these are bad habits.

But no! You just need to tell these developers that once their feature is coded, they should write enough tests to cover it. They will then realise that their code is difficult, if not impossible, to test. They will have to change it to make it more testable. They will also encounter situations that are extremely difficult to test and will leave them aside.

They’ll do this a few times until they learn to write a code upfront that’s ready to be tested, which ironically is very close to what one might call “clean code”!

The Importance of Quality Tests Over Rigid Processes

Writing tests then becomes more natural and not necessarily relegated to the last step. They’ll realise that some pieces of code are difficult to test in a browser or on the command line. So why not just start with a test to set up the conditions, and then write the code afterward? This approach is more convenient in such situations but will never be the most universally natural way to write code.

This gradual shift from Test-Last Development evolves into a more flexible Test-First-When-It-Makes-Sense Development.

Conclusion

The moral of the story is that what matters is the presence of tests of good quality, not the order in which they are written. Writing them first is better from every perspective, but it’s not the only way to do it.

In trying to do the right thing, the TDD approach has inadvertently harmed the software industry by discouraging many developers from the practice of writing tests. Unfortunately, the growing anti-TDD sentiment isn’t helping either, as it only swings the pendulum from one extreme to the other.