test-driven-developmentlisted

# Test-Driven Development (TDD) ## Overview Write the test first. Watch it fail. Write minimal code to pass. **Core principle:** If you didn't watch the test fail, you don't know if it tests the right thing. **Violating the letter of the rules is violating the spirit of the rules.** ## When to Use **Always:** - New features - Bug fixes - Refactoring - Behavior changes **Exceptions (ask your human partner):** - Throwaway prototypes - Generated code - Configuration files Thinking "skip TDD just this once"? Stop. That's rationalization. ## The Minimum Subset **The unit of testing is the behavior in the contract, not the function.** A contract is what the feature promises, what the bug report says is broken, or what the issue asks for. Write one test per behavior in that contract, plus one test per corner case a real caller can produce in production. Nothing else. **The reachability test.** A corner case earns a test only if you can name the caller and the input that reaches it. If you cannot, it is unreachable: the test asserts something no user will ever observe, while still breaking every time the code is refactored. Delete it. **Trivial-code exemption.** Production code may ship with no test when it is a pure passthrough, a constant or configuration declaration, or an accessor with no branching and no computation. This needs no partner permission. Everything else still needs a failing test first. This is narrower than "Configuration files" in the Exceptions list