The Jig is up for TDD

I think automated tests are incredible. I’m a very incautious programmer, and I absolutely love the ability to make changes to my code safe in the knowledge that MeFromThePast wrote a suite of small programs to verify that everything still works as it should.

I also love writing tests, they neatly form the dual to your implementation: linear, focused, and direct instead of branching, wide, and complete. They can structure your thinking for a complex task into a series of decomposed behaviours that makes correctness much closer to achievable.

They are an invaluable tool at every stage of development; but I’ve always been incredulous of some TDD advocates’ assertions that the tests themselves are the thing

1 If the Server Was Burning Down

TDD advocates will likely tell you that you should write your tests before you write your implementation; TDD absolutists might say that your test suite is actually more valuable than your implementation. ¹ When I first encountered these arguments they felt revelatory in their counterintuitive insight. But after developing my skills and practice I have come to disagree; and in the age of the LLM I think these methodologies are less useful than ever.

2 Ease to Read. Right to Write

It’s a weird property of software that it’s often Easier to write than it is to read. This is why, when looking at a tangled and confusing function/system/project one often feels the impulse to just rewrite the whole thing: In the writing we expect to gain an understanding that we’re not receiving just by reading.

But tests are the opposite, they’re easier to read than to write. A test:

1. imports the system under test
2. does some setup
3. performs some action
4. asserts some outcome
5. (optional) go to 3.

But writing a test if often tricky, you have to figure out

• What the PM’s requirements actually mean when translated into formal code
• What setup, if any, is required to get the system into a state where it can actually be tested
• How are you even meant to trigger the behaviour you want to test.

This quality of being easier to read than they are to write make them an excellent candidate for outsourcing: get someone else to handle the hard part, and just review their work when they’re done. And outsourcing has never been more in reach…

3 Large Litmus Model

claude "Please write a test that covers $FILE:$LINE."

That’s it. That’s your new testing strategy

4 No Panacea

Put down your pitchfork, close that comment box. I’m not suggesting some “LLM Only” Software Factory where a swarm of agents churn out 1000s of tests each less informed than the last. Rather, my point is that it’s now much harder to claim that tests are “the thing” we should care about as software developers, and much easier to claim that they are just another tool in our kit for delivering high quality software.

High test coverage was once a tedious slog from 80% to 100%, it’s now just a matter of token cost.

Setting up Fuzzing or Property Based Testing was once the work of several hard-to-advocate-for days of experimentation, now it’s just a matter of token cost.

Converting mangled Jira tickets into a suite of well-defined tests before starting implementation was such a pain that no one bothered, now… it’s not just a matter of token cost, but it’s much easier than it used to be.

5 Going Forward

Keep writing tests. In fact, write MORE tests. But perhaps spend less brainpower on them.