Nobody Has Time for TDD, So Here's the Version That Fits in Your Commute

Let's skip the sermon. You've read the TDD books, you've watched the conference talks, and you've nodded along. Then Monday happened, with its three meetings, a production incident, and a stakeholder who wants the dashboard to "just pop a bit more". Testing lost. It usually does — not because you don't care, but because the version of TDD you were sold assumes a calendar you don't have.

So here's the honest version: what testing looks like when your day is full of other people.

Rule one: test-first for bugs only

Full test-driven development is a discipline, and disciplines need uninterrupted focus. Bugs don't. When something breaks, write the failing test first, before the fix. It takes ten minutes, it proves you understand the problem, and it means the bug can never quietly return.

This is the highest-return habit in software, and it fits in the gaps between meetings. A bug report comes in, you reproduce it as a test, you go to your 11am, you come back and fix it with the safety net already in place. No zen-like flow state required.

The commuter test suite

Here's the idea that changed our team: build a test suite fast enough to run while the kettle boils. Ninety seconds, hard limit.

What goes in it:

• The tests for the code you're currently touching
• A handful of end-to-end smoke tests covering your critical path — login, the main workflow, the thing that makes money
• Nothing else

What stays out: the exhaustive suite, the browser tests with real screenshot comparisons, anything that needs Docker to warm up. Those live in CI, where slowness doesn't cost you attention.

The commuter suite earns its name because it fits into dead time — the gap before standup, the two minutes while a build runs. Fast feedback loops aren't a luxury; they're the only reason anyone runs tests at all. A suite that takes eight minutes is a suite people run once a day, at the end, when the damage is already done.

Coverage targets are quietly making things worse

Controversial opinion, delivered gently: that 80% coverage target your CTO set? It's probably degrading your codebase.

Not because coverage is bad — it's a useful smoke detector. But when a number becomes a target, engineers hit the number, not the goal. You get tests that assert a method returns what the method obviously returns. You get tests that mock the database, the ORM, and half the language, verifying nothing but their own mocks. You get 400 tests that pass and protect no one.

Better metric: ask what happens when someone breaks the login flow. Does something go red? If yes, your tests are doing their job, whatever the coverage dashboard says.

Write tests for the you of six months from now

The best framing I've found for a time-poor developer: tests are documentation that runs. When you write a test for a bug fix, you're leaving a note to future-you explaining what this code was supposed to do — in a format that complains loudly when reality diverges.

That reframe matters, because it changes what you write. You stop chasing percentages and start capturing behaviour: the weird edge case from that support ticket, the customer who did something unexpected with date formats (British ones, naturally — don't get me started on US date parsing), the discount rule that only applies on bank holidays.

A realistic week

• Monday: Bug comes in. Failing test first. Fix. Test stays.
• Tuesday–Wednesday: Feature work, tests written alongside, not ceremonially beforehand.
• Thursday: Ten minutes adding one smoke test to the commuter suite for something scary and untested.
• Friday: Run the whole thing, fix whatever's flaky. Flaky tests are worse than no tests — delete or fix them the same day.

That's it. No ritual, no red-green-refactor ceremony, no coverage gate. Just a small, fast, honest suite that grows one bug at a time — and fits around a calendar full of people who think your estimates are negotiable.