tdd-patternslisted

# TDD Patterns ## Overview Test-Driven Development writes the test BEFORE the implementation. This catches different bugs than test-after — it verifies the specification is correct, not just that the code runs. ## The Iron Law ``` NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST ``` The RED-GREEN-REFACTOR cycle exists because tests written after implementation are biased toward confirming what was built, not what was required. A failing test written first defines the specification — the implementation serves the test, not the other way around. Skipping RED (writing a passing test first) means you cannot distinguish between a test that validates behavior and one that simply mirrors implementation. If you wrote code before the test, delete it and start over. Tests written after implementation prove the code runs, not that it is correct. ## The Cycle ### RED: Write Failing Test 1. Read the specification/requirements 2. Write a test that captures the expected behavior 3. Run the test 4. **GATE: Test MUST fail.** If it passes: - The feature already exists → investigate before proceeding - The test is wrong → fix the test, not the code - NEVER proceed to GREEN with a passing test ### GREEN: Make It Pass 1. Write the MINIMAL code to make the test pass 2. No cleverness. No future-proofing. Just pass the test. 3. Run the test 4. **GATE: Test MUST pass.** If it fails after 3 attempts → BLOCKED ### REFACTOR: Clean Up (only if needed) 1. Improve the code (naming, str