red-green-refactor

# Red-Green-Refactor Methodology You are following the RED-GREEN-REFACTOR cycle for test-driven development. Every new feature, bug fix, or behavior change starts with a failing test. ## The Cycle ### 1. RED Phase — Write a Failing Test 1. **Understand the requirement** — what specific behavior must exist? 2. **Write one test** asserting that behavior 3. **Run the test** — it MUST fail (red) 4. **Verify the failure reason** — not a syntax error, but a missing implementation The test should be focused on ONE behavior, named descriptively, and use clear assertions. **Executable example (Jest):** ```js // calculateTotal.test.js const { calculateTotal } = require('./calculateTotal'); describe('calculateTotal', () => { it('should apply 10% discount when total exceeds 100', () => { const items = [{ price: 60 }, { price: 60 }]; // total = 120 expect(calculateTotal(items)).toBe(108); // 120 * 0.90 }); }); ``` Running this now produces: `Cannot find module './calculateTotal'` — correct RED state. --- ### 2. GREEN Phase — Make the Test Pass Write the **minimum code** needed to pass the test. Don't add anything extra. ```js // calculateTotal.js function calculateTotal(items) { const total = items.reduce((sum, item) => sum + item.price, 0); return total > 100 ? total * 0.9 : total; } module.exports = { calculateTotal }; ``` Run the test — it passes. GREEN achieved. Stop here; resist adding more logic. --- ### 3. REFACTOR Phase — Improve the Code With a passing test as your safety net, clean up the implementation. Run tests after every change. ```js // calculateTotal.js — refactored for clarity const DISCOUNT_THRESHOLD = 100; const DISCOUNT_RATE = 0.9; function calculateTotal(items) { const subtotal = items.reduce((sum, { price }) => sum + price, 0); return subtotal > DISCOUNT_THRESHOLD ? subtotal * DISCOUNT_RATE : subtotal; } module.exports = { calculateTotal }; ``` Test still passes — GREEN maintained. Constants now communicate intent. --- ## End-to-End Example: Adding a New Behavior **Next requirement:** apply a 15% discount when total exceeds 200. **RED** — write the failing test first: ```js it('should apply 15% discount when total exceeds 200', () => { const items = [{ price: 110 }, { price: 110 }]; // total = 220 expect(calculateTotal(items)).toBe(187); // 220 * 0.85 }); ``` **GREEN** — extend the implementation minimally: ```js function calculateTotal(items) { const subtotal = items.reduce((sum, { price }) => sum + price, 0); if (subtotal > 200) return subtotal * 0.85; if (subtotal > 100) return subtotal * 0.9; return subtotal; } ``` **REFACTOR** — remove duplication with a tiered structure: ```js const DISCOUNT_TIERS = [ { threshold: 200, rate: 0.85 }, { threshold: 100, rate: 0.9 }, ]; function calculateTotal(items) { const subtotal = items.reduce((sum, { price }) => sum + price, 0); const tier = DISCOUNT_TIERS.find(({ threshold }) => subtotal > threshold); return tier ? subtotal * tier.rate : subtotal; } ``` Both tests pass — ready for the next cycle. --- ## Workflow Steps 1. **Create or open the test file first** 2. **Write ONE failing test** for the smallest testable unit 3. **Implement minimally** — just enough to pass 4. **Refactor if needed** — while tests stay green 5. **Repeat** for the next behavior ## Decision Points ### Write a new test when: - Adding a new feature or behavior - Fixing a bug (test the bug first, then fix it) - Handling an edge case discovered during implementation ### Don't write a test when: - Pure refactoring (existing tests already cover the behavior) - Non-functional changes (formatting, comments) - Third-party library internals ## Verification Checklist - [ ] All new code has corresponding tests - [ ] Tests fail when the feature is removed - [ ] Tests pass consistently (not flaky) - [ ] Code has been refactored for clarity - [ ] No unnecessary code was added ## Common Mistakes to Avoid 1. **Writing tests after code** — defeats the design benefit of TDD 2. **Writing multiple tests at once** — one test drives one change 3. **Passing tests with hacks** — the test should drive good design 4. **Skipping the refactor phase** — technical debt accumulates 5. **Testing implementation details** — test behavior, not internals ## Integration with Other Skills - **test-patterns**: Patterns for structuring tests - **anti-patterns**: Common testing mistakes to avoid - **debugging/root-cause-analysis**: When tests reveal unexpected failures