When TDD Helps (and When It Does Not)

An honest scorecard

TDD is a tool, not a religion. Where it shines:

• clear specs: you know the expected outputs, like fizzbuzz or a tax rule, so tests write themselves
• bug fixes: reproduce the bug as a failing test first, then fix. The red-to-green flip proves the fix, and the test guards against the bug returning forever
• tricky pure logic: parsers, date math, pricing, anywhere edge cases breed

Where it fights you:

• exploration: you do not know what you are building yet, so specs do not exist to test against
• visual work: whether a layout looks right is not an assert
• thin glue code: a one-line wrapper rarely earns a test

The pros' habit even outside strict TDD: never fix a bug without first writing the test that catches it. That single rule carries most of TDD's value.