test-driven-development

Test-Driven Development (TDD) SOP

Write a failing test, write just enough code to pass it, then refactor. Repeat. This SOP covers the full Red → Green → Refactor cycle with concrete examples.

When to Use

• User wants to build a feature with test coverage from the start
• User wants to practice TDD on an existing or new function
• User is adding behavior to an existing module and wants to do it safely
• User is fixing a bug and wants to prevent regression

---

The TDD Cycle

  ┌─────────────────────────────────────────────────────┐
  │                                                     │
  │   RED ──────→ GREEN ──────→ REFACTOR ──────→ RED   │
  │                                                     │
  │   Write a   Make it pass   Clean it up   Next test  │
  │   failing   with minimal   without        (repeat)   │
  │   test      code           breaking tests            │
  └─────────────────────────────────────────────────────┘

Non-negotiable rules:

1. Never write production code before a failing test
2. Write only enough production code to make the failing test pass
3. Never refactor on a red test — only refactor when all tests are green
4. Run tests after every change, no matter how small

---

Step 1 — RED: Write a Failing Test

Test Anatomy (Arrange → Act → Assert)

def test_calculate_order_total_applies_discount():
    # Arrange — set up inputs
    items = [
        {"name": "Widget", "price": 10.00, "quantity": 3},
        {"name": "Gadget", "price": 25.00, "quantity": 1},
    ]
    discount_percent = 10

    # Act — call the code under test
    total = calculate_order_total(items, discount_percent)

    # Assert — verify the result
    assert total == 49.50  # (30 + 25) * 0.9

Good test names describe behavior, not implementation:

• test_calculate_order_total_applies_discount — good
• test_total_function — bad
• test_with_10_percent_off_correctly_applies_the_discount_to_three_items — too verbose

Run It — Confirm It Fails