Test-Driven Development: Just One Tool Among Many

Spoiler alert: we’re stating the obvious here.

TDD is there to help you

Test-Driven Development (TDD) gets people worked up in a way I don’t quite understand. The debate quickly becomes polarized around the idea that, simply because one is a proponent of this method, one would inevitably want to use it everywhere and for everything.

The perfect use case for TDD is the application’s core domain, where all the business logic is concentrated. If you’re working with Hexagonal Architecture, that’s all the code inside the hexagon. To be honest, I can’t do it any other way anymore: in my own experience, this method has become synonymous with safety and speed.

Beyond that, there’s no one-size-fits-all approach. We can’t stress this enough: TDD is there to help you. If you find that it isn’t helping you, maybe it’s not the right tool, or perhaps you’re using it incorrectly. In any case, be critical, trust yourself, and adjust your approach.

Be critical and pragmatic

Let’s get specific: you’re using React; does it make sense to develop your components using TDD? In my experience, no.

When interaction logic emerges, paging for example, I extract it by creating a pure function, which I develop by letting the tests guide me (TDD).

But for everything else, such as verifying that a callback is indeed called when you click a button, running the test manually in the browser seems far more efficient to me than doing TDD at all costs. And don’t forget to capture the behavior once the result is correct: a simple snapshot, an interaction test using DOM mocking, or even an end-to-end test, depending on the situation. In other words, “test-after.”

Ultimately, this isn’t strictly TDD, but the benefits are clear:

• During the development phase, baby steps and rapid feedback, so bugs don’t pile up;

• Tested code, to prevent regressions;

• Code documented by tests.

So what if it’s not TDD? All that matters is the result and the Developer Experience (DX).

Don’t give in to the law of the instrument

When you first discover TDD, it’s common to have the zeal of a new convert, that is, the urge to use it everywhere and for everything, especially when you shouldn’t. This is a perfect illustration of the “law of the instrument,” which essentially states that if the only thing you have is a hammer, you’ll tend to see nothing but nails.

The concept of the test pyramid specifically emphasizes the need to learn how to use different types of tests. Relying solely on unit tests would not provide all the necessary guarantees. Relying solely on end-to-end tests would be utterly inefficient. What am I saying? It would be heresy.

Learning TDD takes very little time. Learning to distinguish between situations where it’s appropriate to use it and those where it isn’t takes significantly longer. The software craftsman has a large toolbox; his art lies in using those tools wisely.