tddlisted

# Test-Driven Development ## Philosophy **Core principle**: 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" — and survives a refactor because it does not know the internal structure. The warning sign of a bad one: it breaks when you rename an internal function, though behaviour did not change. See the `references/` directory alongside this skill file for supporting material: `tests.md` (examples) and `mocking.md` (mocking guidelines). Read them from the same directory you read this skill file from. ## Anti-Pattern: Horizontal Slices **DO NOT write all tests first, then all implementation** — RED as "write all tests", GREEN as "write all code". Tests written in bulk test *imagined* behaviour: they verify the shape of things (signatures, data structures) rather than what a user can do, and they commit you to a test structure before you understand the implementation. **Correct approach**: vertical slices via tracer bullets. One test → one implementation → repeat, so each test responds to what the previous cycle taught you. ``` WRONG (horizontal): RIGHT (vertical): RED: test1..test5 RED→GREEN: test1→impl1 GREEN: impl1..impl5 RED→GREEN: test2→impl2 ``` ## Workflow ### 1. Planning When exploring the codebase, use the project's domain glossary so that test names and interface vocabulary match