Exercises — TDD — Red-Green-Refactor cycle

1. Refactor — renaming changes readability, not behavior; you did it only while green.
2. Red — you wrote a failing test for behavior that doesn't exist. (It fails because the function/return is missing — the "right reason".)
3. Green — the minimum code (even a hardcoded 0) to make a specific test pass.

Broken Red. A valid Red fails because an assertion is false — the behavior is genuinely missing or wrong. An ImportError/typo means the test never even ran the assertion, so it proves nothing about your logic. Fix: create the stub (def divide(a, b): pass) so the test runs and fails on the assertion. Only then is Red trustworthy.

Cycle 1 — Red (smallest behavior — the blue dot):

def test_square_of_2_is_4():
    assert square(2) == 4

Cycle 1 — Green (fake it, minimum to pass — one of the dashed wrong lines):

def square(n):
    return 4        # hardcoded — passes the single test

Cycle 2 — Red (add the orange dot; the hardcode must break):

def test_square_of_3_is_9():
    assert square(3) == 9

This fails: square(3) returns 4, not 9. Good — the second example triangulates (now only the honest rule survives). Cycle 2 — Green (the solid green line — simplest thing passing both):

def square(n):
    return n * n

Both tests pass. We generalized only because a second test forced us to.

Red — reproduce the zero bug as a test (note the import pytest at the top of the test file):

import pytest
 
def test_percent_of_zero_raises():
    with pytest.raises(ValueError):
        percent(5, 0)

Fails now: the code raises ZeroDivisionError, not ValueError. Red — the three extra boundaries (each a separate failing test, driven one at a time):

import pytest
 
def test_percent_negative_whole_raises():
    with pytest.raises(ValueError):
        percent(5, -10)
 
def test_percent_negative_part_raises():
    with pytest.raises(ValueError):
        percent(-50, 200)
 
def test_percent_non_numeric_raises():
    with pytest.raises(ValueError):
        percent("five", 200)

Green — minimal guards covering every edge case:

def percent(part, whole):
    if not isinstance(part, (int, float)) or not isinstance(whole, (int, float)):
        raise ValueError("part and whole must be numbers")
    if whole <= 0:
        raise ValueError("whole must be positive")
    if part < 0:
        raise ValueError("part cannot be negative")
    return part / whole * 100

• The type guard rejects "five" before any arithmetic (non-numeric input).
• whole <= 0 catches both whole == 0 (the original divide-by-zero) and whole < 0 (nonsense).
• part < 0 rejects a negative amount, which has no meaning here. A valid call: $percent(50,200)=\frac{50}{200}\times 100=25.0$. All four bug/boundary tests stay in the suite forever — regression guards, so none of these cases can silently return.

They lost the "prove the test can fail" guarantee. Because it never went Red, they never learned the test has teeth. Concrete risk: the test might assert something already-true-by-accident (e.g. asserting f(x) is not None when the function can't return None anyway). Such a test will never catch a future bug — it's a silent pass. Fix: temporarily break the production code (or comment out the fix) to confirm the test goes red, then restore.

No. Refactor means change structure, not observable behavior. Adding "negatives return None" is new behavior, so it must be driven by its own Red test first — it is not a refactor at all. The suite staying green only means the behavior is untested, not that it's unchanged. Correct move: write a failing test specifying what negatives should do, then Green, then optionally Refactor.

A failing test tells you the whole block is broken but not which behavior. With one behavior per test, a red result names the culprit directly ("checkout total wrong"). The giant test collapses three independent signals into one bit of information, so you must debug manually to find the sub-fault — exactly the pain TDD's tiny loops remove. Granularity = diagnostic power.

Cycle 1 — Red (plain number case):

def test_4(): assert fizzbuzz(4) == "4"

Cycle 1 — Green (fake it — the simplest pass):

def fizzbuzz(n):
    return "4"

Cycle 2 — Red (force generalization off the hardcode):

def test_6(): assert fizzbuzz(6) == "Fizz"

Cycle 2 — Green (add the Fizz branch; plain numbers now use str(n)):

def fizzbuzz(n):
    if n % 3 == 0: return "Fizz"
    return str(n)

Cycle 3 — Red (drive the Buzz rule):

def test_10(): assert fizzbuzz(10) == "Buzz"

Cycle 3 — Green:

def fizzbuzz(n):
    if n % 3 == 0: return "Fizz"
    if n % 5 == 0: return "Buzz"
    return str(n)

Cycle 4 — Red (drive the both-rules case — this one breaks the code above, which would return "Fizz" for 15):

def test_15(): assert fizzbuzz(15) == "FizzBuzz"

Cycle 4 — Green (special-case both first):

def fizzbuzz(n):
    if n % 3 == 0 and n % 5 == 0: return "FizzBuzz"
    if n % 3 == 0: return "Fizz"
    if n % 5 == 0: return "Buzz"
    return str(n)

Refactor (all four tests green — remove the branchy duplication, behavior identical, so no new test needed):

def fizzbuzz(n):
    out = ""
    if n % 3 == 0: out += "Fizz"
    if n % 5 == 0: out += "Buzz"
    return out or str(n)

Outputs: fizzbuzz(4)="4", fizzbuzz(6)="Fizz", fizzbuzz(10)="Buzz", fizzbuzz(15)="FizzBuzz". The or str(n) line handles the "neither rule fired" case — the fully general branch. Because the refactor left every test green, it is provably safe.

Cycle 1 — Red (the base "not divisible by 4 → no" case):

def test_2001(): assert is_leap_year(2001) == False

Cycle 1 — Green (fake it — the simplest pass):

def is_leap_year(y):
    return False

Cycle 2 — Red (force the % 4 rule):

def test_2004(): assert is_leap_year(2004) == True

Cycle 2 — Green:

def is_leap_year(y):
    return y % 4 == 0

Cycle 3 — Red (century exception — 1900 is divisible by 4 but is NOT a leap year):

def test_1900(): assert is_leap_year(1900) == False

Cycle 3 — Green:

def is_leap_year(y):
    if y % 100 == 0: return False
    return y % 4 == 0

Cycle 4 — Red (exception-to-the-exception — 2000 is a century but divisible by 400, so it IS leap):

def test_2000(): assert is_leap_year(2000) == True

Cycle 4 — Green (final):

def is_leap_year(y):
    if y % 400 == 0: return True
    if y % 100 == 0: return False
    return y % 4 == 0

Refactor: nothing to clean — three tidy guards, all four tests green. Results: 1900 → False, 2000 → True, 2004 → True, 2001 → False. Each cycle's Red test broke the too-simple version, driving exactly one new branch.

Use a test double — a stand-in object that replaces the real dependency. A stub returns a canned answer (e.g. "payment OK") so your logic can run without the network; a mock additionally asserts it was called correctly (right amount, right card). This keeps the Red-Green loop in seconds instead of network round-trips, and removes flakiness (no real API to time-out or rate-limit). Risk to offset: doubles test your code against your assumptions about the API, not the real thing — if the real API changes, your green suite won't notice. Offset it with a small number of slower integration tests (run in Continuous Integration) that hit a sandbox environment and run less often. Net result: TDD stays fast on doubles, integration keeps you honest against reality.

Guiding idea: Single Responsibility / Open-Closed — extract the shared "apply divisibility rules" logic into one place so each rule is added without editing the core (open for extension, closed for modification). What must never change during the extraction: observable behavior — every existing test stays green at every micro-step. If a test goes red, the refactor introduced a behavior change and must be reverted or re-driven with a new test.

• With TDD: $9$ defects at $1$ unit + $1$ defect at $100$ units $=9+100=109$ units for $10$ defects.
• Average per defect with TDD $=109/10=10.9$ units.
• All in production: $10\times 100=1000$ units, average $=100$ units.
• Ratio: $100/10.9\approx 9.17\times$ cheaper per defect. The takeaway matches the parent note: shrinking the detection window (Red catches it seconds after you type it) is the dominant lever on cost — one slipped defect still dwarfs nine cheap ones, so the goal is to push the catch-rate at Red as high as possible.

L1 recognizes phases ::: name Red / Green / Refactor and explain "right reason to fail". L2 runs a cycle ::: fake it, triangulate with a second example, capture a bug and its boundaries as tests. L3 analyzes ::: never-red tests are toothless; new behavior is not a refactor; small tests localize failure. L4 synthesizes ::: drive a whole feature one Red at a time, simplest case first. L5 masters ::: doubles vs integration, SOLID-guided refactor, cost economics, coverage is not correctness.

TDD (Test-Driven Development) is: write a tiny test that fails for the right reason, add the least code to make it pass, tidy without changing behavior, and repeat — using small examples (triangulation) to force the code to generalize and edge-case tests to guard every boundary, so every behavior you care about has a test that will turn red the instant it breaks.