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). ## 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: the `codebase-design` skill). Tests live at seams, never against internals. **Test only at agreed seams.** Seams the user approved in the spec (via `/spec`) are already agreed — test at them without re-asking. Anywhere else, write down the seams under test and confirm them with the user before writing any test. You can't test everything — agreeing the seams up front is how testing effort lands on the critical paths and complex logic instead of ev