tddlisted

# Test-Driven Development TDD is the red → green loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the anti-patterns, and the rules of the loop. Every section applies on every cycle — consult them before and during the loop, not after. Match test names and interface vocabulary to the project's domain glossary (the `AGENTS.md` glossary section, or `CONCEPTS.md` if the project has one). Working from a spec that folded in the standing decisions — `/spec` step 2 does, flagging what conflicts — take those decisions as read. Otherwise, where the loop config enables the ADR store, read the ADRs bearing on the area you are touching before naming tests and interfaces, so a seam or an interface does not re-litigate a decision already made. The loop config is `docs/agents/cantrips-loop.md`; when that doc is absent, the ADR store is off. ## What a good test is Tests verify behavior 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" tells you exactly what capability exists — and survives refactors because it doesn't care about internal structure. See [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking guidelines. ## Seams — where tests go A **seam** is the public boundary you test at: the interface where you observe behavior without reaching inside (full vocabulary: `