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. ## When to use **Always:** new features, bug fixes, refactoring, behavior changes. **Exceptions (ask the maintainer first):** throwaway prototypes, generated code, configuration files. Thinking "skip TDD just this once"? That's rationalization — stop. ## The iron law ``` NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST ``` Wrote code before the test? Delete it. Don't keep it "as reference," don't adapt it while writing the test, don't look at it. Implement fresh from tests. ## Red-Green-Refactor ``` RED: write one minimal failing test -> verify it fails for the right reason (not a typo, not existing behavior) GREEN: write the minimal code to pass -> verify it passes, and nothing else broke REFACTOR: clean up, keep tests green, no new behavior -> next failing test ``` ### RED — write a failing test One behavior, clear name, real code (mock only if unavoidable). Good: `test('retries failed operations 3 times', ...)` — tests real behavior. Bad: `test('retry works', ...)` with a mock asserting call count — tests the mock, not the code. ### Verify RED — mandatory, never skip Run the test command. Confirm: it fails (not errors), the failure message is the expected one, and it fails because the feature is missing — not because of a typo. If it passes, you'r