tdd-patternslisted

# TDD Patterns Domain skill for test-driven development: Red-Green-Refactor cycle, test quality, and runner discipline. ## Iron Law **IF YOU DIDN'T WATCH THE TEST FAIL, YOU DON'T KNOW IF IT TESTS THE RIGHT THING.** A test that has never failed might pass for the wrong reason. The RED phase exists to prove the test is valid. ## Red-Green-Refactor Cycle For each feature or fix, track the TDD cycle with tasks: ``` TaskCreate("RED: Write failing test for {behavior}", "Minimal test describing desired behavior. MUST fail on first run.") TaskCreate("GREEN: Implement {behavior}", "Simplest code to make the test pass. No cleverness.") TaskCreate("REFACTOR: Clean up {behavior}", "Improve quality. All tests must still pass after each step.") ``` ### RED: Write a Failing Test TaskUpdate(RED task, status: "in_progress") 1. Write the **minimal** test that describes the desired behavior 2. Run it — it MUST fail 3. Verify it fails for the **right reason** (not a syntax error, not wrong import) TaskUpdate(RED task, status: "completed") ### GREEN: Make It Pass TaskUpdate(GREEN task, status: "in_progress") 1. Write the **simplest** code that makes the test pass 2. No cleverness. No optimization. No "while I'm here" improvements. 3. Run the test — it MUST pass now TaskUpdate(GREEN task, status: "completed") ### REFACTOR: Clean Up TaskUpdate(REFACTOR task, status: "in_progress") 1. Improve code quality (naming, structure, duplication) 2. Run ALL tests after each refactor step —