TDD up close: How it works. What it assumes.

First of all, TDD is not ATDD or BDD.

That is, Test-Driven Development is not Behavior-Driven Development or Acceptance Test-Driven Development. Those - essentially the same thing - are a "black box" testing process whereby business outcome-oriented tests are written in advance of, or at the same times as, the application code for a story.
 
ATDD and BDD are similar ideas – I will treat them as the same here and use the term ATDD for brevity. TDD is definitely something else. TDD is a development approach, whereby very low level "unit" tests - tests that exercise individual "functions" or "methods" inside the code - are written before each corresponding function or method is written.

The alleged value of TDD is that it (1) encourages one to think clearly about the behavior of one's code from the start; (2) traps deviations from intended behavior when code changes are later made, providing a kind of "safety net" when code is maintained; and (3) when coupled with a "continuous integration" process that requires that all tests pass for a code change to be considered "done", encourages tests to be maintained over time. There are more benefits, but those are the main ones. The last one is huge, because maintaining tests is very challenging. TDD solves that, at least in terms of unit level tests.

TDD has made a great contribution, and so while I disparage it in this website, my criticism is very specific. I criticize it mainly because I feel that too many people feel that TDD is for everyone, and it is not; and I criticize it because things have changed: unit tests are not as important as they once were. We need to accept the contribution that TDD has made, and be willing to move on. To those of us who hold onto TDD like a religion, I say, "Let go".