Test-driven development

TDD is a design technique that produces tests as a by-product. The tests are valuable; the design pressure is the point. Writing the test first forces you to use the interface before you build it, and interfaces that are painful to call are painful to test — you find out in thirty seconds instead of after the implementation is finished.

The cycle is small on purpose. If a cycle takes more than a few minutes, the step was too big.

The loop

Red — write a failing test

One behaviour, stated from the caller's side. Run it and watch it fail.

Watching it fail is not ceremony. A test that passes before the code exists is testing nothing, and this is a genuinely common mistake — a typo'd assertion, a test the runner never collected, a mock that satisfies itself. The failure message is also your first piece of design feedback: if it is incomprehensible, fix the test now.