test-driven-developmentlisted

# Test-Driven Development Write the test before the code. The test is how you find out the code works — and "should work" is not "works". This is a discipline skill: you *will* feel pressure to skip it, and the whole point is not to. ## When to use - Any feature or bugfix with logic or behavior. - A bugfix: start with a failing test that reproduces the bug, then fix it. - **Skip** for throwaway spikes (then delete the spike and rebuild under a test), pure config or content with no logic, or generated code. ## The cycle Before the first test, pin down the public interface — what goes in, what comes out, the named behaviors. If you can't yet name the test, the interface isn't decided yet. **RED — write a failing test.** One small test for the next behavior. Run it. Watch it fail, and read the failure: it must fail because the behavior is missing, not because of a typo or an import error. A test you never saw fail proves nothing. Keep the failure you watched — quote a line of it in the cycle's commit message or task notes: an after-the-fact "I watched it fail" is an assertion, the saved output is evidence. **GREEN — make it pass, minimally.** Write the least code that turns the test green. No extra cases, no speculative generality. Run it; confirm green. **REFACTOR — clean up under green.** With the test passing, remove duplication and fix names and structure. Re-run; it stays green. Commit. Then the next RED. ## Hard stops Each of these means **stop, delete the unveri