TDD in the Real World — What 24 Years on Production Systems Taught Me

5 MINS

I've practised TDD across financial services, investment banking, and telecom — three industries where a bad release isn't a meme on Twitter, it's a regulator on the phone. Here's what survives outside the textbook.

TDD is a thinking tool, not a typing tool

Most TDD critics treat it like a typing exercise — "write the test, then write the code". That misses the point entirely.

The value of TDD isn't the test that gets committed. It's the conversation you have with yourself about the interface before you build it. Writing the test forces you to answer two questions you'd otherwise dodge:

What is this thing actually called? The class, the method, the parameters — naming is design.

What is the minimum it has to do? Not "what could it eventually do" — what does the test need it to do, right now? Half my bugs over 24 years would have been caught if I'd answered those two questions before reaching for the keyboard.

The places TDD doesn't help

I'm not a TDD purist. There are places where it doesn't earn its keep:

Genuinely exploratory code — when you don't know what you're building yet, tests slow you down. Spike first, test second.

UI layouts — pixel-level testing is brittle and expensive. Use snapshot tests sparingly, and only at the boundary of behavior.

Once-off scripts — if it'll run twice and never again, just write it. The mistake is treating TDD as a religion. It's a tool. Use it where it pays.

What I tell juniors about tests

A test that passes is not the same as a test that proves something. Always ask: "what specifically would have failed if this test wasn't here?"

Test the seam, not the implementation. The test is supposed to outlive the code it tests. If you have to change the test every time you change the function, you're testing the wrong thing.

A flaky test is a worse smell than no test. Fix it or delete it. There is no middle ground.

One assertion per test. When the test fails, the message should tell you what broke without you having to read the code.

The thing they don't put in the books

The reason I still write tests after 24 years isn't discipline. It's memory. I don't trust my own brain to remember what this code was supposed to do six months from now. The test is a note from past-me to future-me, written in the only language we both speak fluently.

That's the real value of TDD. Everything else is a side effect.

Picking AWS Is Not a Strategy

Manik skipped presentations and built real AI products.

Manik Wadhwa was part of the January 2026 cohort at Curious PM, alongside 13 other talented participants.