test-driven-developmentlisted

# Test-driven development ``` NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST ``` If you didn't watch the test fail, you don't know that it tests the right thing. Following the letter of this rule is the spirit of it. Exceptions only with the user's explicit agreement: throwaway spikes, generated code, pure configuration. **Legacy code without tests is not an exception.** Use changing-legacy-code and pin current behavior first. ## The cycle 1. **RED.** Write one minimal test for one behavior. Give it a clear name, use real code, and mock only true boundaries (network, clock, hardware, payment provider). Before you write it, name the production change that would make it fail. 2. **Verify RED. Mandatory.** Run it. It must *fail* (not error) with the expected message, *because the feature is missing*. - Passes immediately? You're testing existing behavior. Fix the test. - Errors? Fix the error and re-run until it fails for the right reason. 3. **GREEN.** Write the simplest code that passes. No extra options, no speculative generality, no drive-by refactors. 4. **Verify GREEN. Mandatory.** Run the test, then **the project's full test command**. The output must be clean: no new warnings or errors. If another test fails, fix it now or report it by name. A red test you saw scroll past and didn't mention falsifies your report. 5. **REFACTOR**, only while green: remove duplication, improve names. Re-run. Add no behavior. Code written before its test is deleted and rewritte