Crisis of Faith

Ever since a copy of Test Driven Development by Example fell into my hands, I’ve been a devoted follower of the discipline. Like any good believer, I’ve often strayed from its principles, and I’m still far from mastering the practice in depth. Still, since it was first revealed to me, I’ve defended its "truth" as the best possible approach. But I must admit that lately, I’ve been going through a bit of a crisis of faith.

What’s happening to me with tests?

Experience has taught me that writing good tests consistently is far harder than it looks—and that even when we do it well, the benefits can quickly fade if the environment doesn’t support them. Here are some of the reasons.

• The real world is messy
  Outside the controlled conditions of a carefully crafted project, in most real-world scenarios we have little or no control over the tests that existed (or worse, didn’t exist) before we arrived. Our ability to fight entropy is limited, and despite our best efforts, disorder inevitably creeps in.

• There's no consensus
  While it's relatively easy to agree on code style, reaching alignment on how to test is much harder. Should we use mocks? If so, how many and what kind? What’s the optimal unit-to-feature test ratio? Reviewing every detail of a test in a pull request is often impractical given the pace of development.

• Tests are more complex than they seem
  Tests often end up being longer and more complex than the code they’re meant to verify. Whether it’s due to numerous edge cases or the setup logic, they grow fast. Even when practicing TDD, it’s difficult to keep that complexity under control.

• They’re hard to maintain
  Long, cryptic, poorly named. What made perfect sense when written can become incomprehensible months later. And since tests tend to accumulate and rarely get deleted, maintenance becomes increasingly expensive.

• Developers take shortcuts
  There’s almost never time to write the tests we’d like to. Under pressure, many developers resort to the minimal test that unblocks progress. This leads to duplication, overlapping coverage, and fragility. Flaky tests become inevitable.

• We lose trust
  When tests fail randomly, and we can’t keep up with maintaining them, we start to ignore them. First we mark them as skip, then we stop writing them with care altogether. And so, the vicious cycle feeds itself.

So, now what?

I haven’t stopped believing in the value of testing—far from it. But I do think we need a more nuanced view. No dogma, no disdain: testing requires discipline, but also context and flexibility.

Maybe the goal isn’t to test more, but to test better. With more intention, more purpose, more team alignment. Less heroism, more sustainability. After all, trust in software doesn’t come from thousands of lines of tests—it comes from tests we can actually believe in.

exit(0);