A developer is halfway through a small pricing change when the question appears in review: where are the tests? The room gets quiet in that familiar way. Everyone agrees tests are good. Everyone also remembers the last time a simple change became two hours of mocking, fixtures, and brittle setup. TDD sounds responsible, but on a busy delivery week, the honest question is still there: is it worth the time?
Test-Driven Development is usually described by its loop: write a failing test, write the smallest code that passes, then refactor while the test stays green. Red, green, refactor. The idea is simple enough to say in one sentence, but the value is not only in having tests afterward. The value is in forcing the engineer to describe behavior before becoming attached to an implementation.
That order changes how code is designed. When you write the test first, you meet the code from the outside. You ask what input should be accepted, what output should be produced, what edge cases matter, and what a caller should not need to know. Awkward tests often reveal awkward design. If one small rule needs half the application booted just to test it, the code may be too coupled. If every test needs five mocks, the boundaries may be unclear. TDD makes those costs visible earlier.
TDD is often worth the time when the logic is important, tricky, or likely to change. Pricing rules, permission checks, scheduling behavior, data transformations, validation, state machines, and retry decisions are good candidates. These areas usually have enough edge cases that testing after the fact becomes a memory exercise. Writing tests first helps the team slow down at the moment where precision matters most.
It is also useful before refactoring. A small characterization test can capture current behavior before the code is cleaned up. Then the team can change structure without guessing whether behavior moved. This is one of the quiet strengths of TDD: it can make refactoring less emotional. The discussion shifts from whether the new code feels cleaner to whether the visible behavior remains protected.
But TDD is not free. It can slow exploration when the team does not yet understand the problem. During a spike, prototype, or UI sketch, writing tests first may create more friction than clarity. Sometimes the right first step is to learn, throw something away, and then return with tests once the shape is clearer. Treating TDD as a rule for every line of code can turn a helpful practice into theater.
TDD also becomes painful when tests are written against implementation details instead of behavior. If every refactor breaks the tests while the feature still works, the tests are not giving safety. They are freezing the wrong thing. Good TDD asks what the unit promises, not which private helper it calls. That distinction takes practice, and it is one reason teams should review tests with the same care they review production code.
Mocking deserves special caution. A mock can isolate a piece of logic and make a test fast. Too many mocks can create a small imaginary system where everything passes because the test taught the code to talk to fake collaborators in a very specific way. The result feels safe until integration fails. A healthy test suite usually mixes levels: focused unit tests for rules, integration tests for important boundaries, and a few end-to-end checks for critical flows.
The time question should include the cost of not doing it. A bug in a permission rule may cost hours of incident response, support explanation, and careful data repair. A missing test around billing can make every future change slower because nobody wants to touch the code. In those cases, TDD may feel slower at the keyboard and faster across the life of the feature. The accounting only makes sense when we count maintenance, not only initial typing.
The best teams I have seen do not perform TDD as identity. They use it where it gives leverage. They write tests first for hard rules, risky changes, and code they expect to refactor. They skip or delay it for disposable experiments. They keep tests readable. They delete tests that no longer serve behavior. They treat the loop as a thinking tool, not a badge.
So is TDD worth the time? Sometimes very much. Sometimes not yet. The better question is what kind of uncertainty you are facing. If you are uncertain about what the product should do, talk, prototype, and clarify. If you are uncertain about whether the code will keep doing the right thing after change, TDD can be a calm and practical investment.
The next time a review asks for tests, the useful conversation is not whether TDD is good in general. It is what risk this change carries, what behavior should be protected, and what kind of test would make the next change easier. That conversation is where testing stops being ceremony and starts becoming part of how a team thinks.