TDD

Test-driven development is the red → green loop. Consult this guidance before and during every cycle. The purpose is not merely to produce coverage; it is to produce tests worth keeping because they describe behavior through stable public interfaces.

When exploring the repository, read CONTEXT.md, docs/glossary.md, relevant ADRs, repository instructions, and nearby tests. Use the project's domain vocabulary in test names and fixtures.

What makes a good test

Tests verify externally observable behavior through public interfaces, not implementation details. A good test reads like a specification, for example:

user can check out with a valid cart

Prefer tests that survive internal refactoring. Expected values must come from an independent source of truth such as the specification, a worked example, or a known-good literal.

Testing seams

A seam is the public boundary where behavior can be observed without reaching into internals. Test at the highest useful seam, prefer existing seams, and avoid creating a new seam unless it provides meaningful leverage.