tdd

Test-Driven Development

TDD is a design discipline, not a testing habit. Kent Beck's rule is absolute: no production code is written except to make a failing test pass, and no more of it than the test requires. The test comes first because it forces the interface to be designed from the caller's side before an implementation exists to bias the design.

Phase 1: The cycle

One cycle, repeated, never skipped:

1. Red. Write the smallest test that expresses one new piece of behaviour, for code that does not yet support it. Run it. Confirm it fails, and fails for the reason you expect; a test that fails on a typo or a missing import isn't red for the right reason.
2. Green. Write the minimum production code that makes the test pass. Resist the urge to generalize or handle a case the test didn't ask for; a case not yet demanded by a test is a case not yet designed, and designing it now is a guess.
3. Refactor. With the suite green, improve the internal structure, naming, and duplication; behaviour does not change, only shape. Run the suite after every small edit; if it goes red, the refactor introduced a real change, not just a cleanup, and needs to be undone or reconsidered.

Each cycle is a vertical slice: one behaviour, one test, one minimal implementation, then the next cycle picks the next behaviour. Writing a batch of tests up front for behaviour that doesn't exist yet is not TDD; it's testing an imagined shape, and the tests go insensitive to what implementation actually teaches you as you build.

Phase 2: What makes a test worth keeping (FIRST)

• Fast. A slow suite gets run less often, which defeats the purpose of a tight feedback loop: milliseconds, not seconds, for the unit layer.
• Isolated / Independent. Any test can run alone or in any order, with no shared mutable state leaking from another test. A test that only passes after a specific other test ran first is not a test, it's a trap.
• Repeatable. Same result every run, in any environment: no dependence on wall-clock time, network availability, or random seed unless pinned.
• Self-validating. Pass or fail, with no human reading output to decide: an assertion, not a console.log someone has to eyeball.
• Timely. Written just before the code that makes it pass, not after. A test written after the implementation tends to assert what the code happens to do, not what it should do.