I’m going to quote anonymously from someone who deleted their tweet: “It’s easy to write untestable code which is why writing tests first guards against that.” This is a super common argument for doing TDD, but when you dig into it, it’s actually circular logic. 🙇♂️
“It's easy to write untestable code" is only true if you insist on testing things in isolation at a unit level. In practice, I find even the most abhorrent one hundred line methods quite testable with headless browser tests, regardless of how the code is structured.
I’ll give you a concrete example: github.com/andrewculver/k… . I, admittedly, wrote this method. It’s the bane of many developers, and infamous among it’s users, but in the six years since I wrote it, it’s helped facilitate at least ten million dollars in Stripe subscriptions.
Furthermore, despite being 121 lines long, it was trivial to achieve complete test coverage (when developing Bullet Train) using a series of steps in a single headless browser test. This method is *only* difficult to test when you insist on testing at a unit level in isolation.
So this whole argument about doing TDD to promote writing “testable code” falls really flat amongst folks like myself who favor headless browser tests. The vast majority of code is testable by default if you’re not concerned about testing in isolation.
In situations where something isn’t easily testable with feature tests, by all means, write a lower-level integration test. And if an integration test doesn’t do the trick, then go ahead and write unit tests. And if it’s hard to test, by all means, refactor so it’s “testable.”
But to say you should do TDD because it promotes writing code that is testable in isolation, that’s circular logic, because you only need that code to be testable in isolation because you’re doing TDD. 🔁
