test-driven-development

# Test-Driven Development Enforce the RED-GREEN-REFACTOR cycle for all implementation work. Tests define the design. Code satisfies the tests. Refactoring improves the design without changing behavior. ## Iron Law > **TESTS FIRST, ALWAYS** > > Write the failing test before the production code. No exceptions. If you catch > yourself writing production code without a failing test, stop immediately, delete > the production code, write the test, watch it fail, then write the minimum code > to make it pass. The test IS the specification. --- ## The Cycle ### Step 1: RED — Write a Failing Test Write a test that describes the behavior you want. Run it. Watch it fail. The failure message IS your specification. ``` Describe what the code SHOULD do, not how it does it. One behavior per test. One assertion per test (ideally). Name tests as sentences: "returns error when email is invalid" ``` **Checkpoint:** The test MUST fail before proceeding. A test that passes immediately proves nothing. ### Step 2: GREEN — Write Minimum Code to Pass Write the simplest production code that makes the failing test pass. No more, no less. ``` Hardcode first if that's simplest. Generalize when the next test forces it. Don't write code "you'll need later." Write code the test demands NOW. Don't optimize. Don't refactor. Don't clean up. Just pass the test. ``` **Checkpoint:** All tests pass. If any test fails, fix it before moving on. ### Step 3: REFACTOR — Improve Without Changing Behavior ...