TDD

TDD is the red → green loop. This is the reference that makes the loop produce tests worth keeping: what a good test is, where tests go, the anti-patterns, and the rules of the loop. Apply every section on every cycle, not after.

Apply this loop when test-first is the chosen flow. Preserve an approved tests-after flow rather than changing it. Read the project's authoritative glossary/spec record so test names match domain language, and respect recorded decisions.

What a good test is

Tests verify behaviour through public interfaces, not implementation details. Code can change entirely; tests shouldn't. A good test reads like a specification — "user can checkout with valid cart" names the capability — and survives refactors because it doesn't care about internal structure.

Seams — where tests go

A seam is the public boundary you test at: where behaviour is observable without reaching inside ([[z-deep-modules]]).

Use the agreed seams. Existing caller approval or a dispatch plan is sufficient. Follow [[z-testing-strategy]] for acceptance boundaries and residual-risk exceptions. The red-green loop can run through a public product boundary. Resolve genuinely missing seam decisions before expanding scope. Under zapply, report an unlisted seam to the driver rather than asking the user from the worker.

Anti-patterns