A complete result you can execute

The original block below represents the final green state rather than every intermediate stage. It requires Python 3 and only the standard library. Save it as coupon_tdd.py and run python3 coupon_tdd.py without -O, which disables assertions.

def discount_cents(subtotal_cents: int, coupon_active: bool) -> int:
    if type(subtotal_cents) is not int or subtotal_cents < 0:
        raise ValueError("subtotal must be non-negative integer cents")
    if not coupon_active or subtotal_cents < 2000:
        return 0
    return min(500, subtotal_cents // 10)


cases = [
    (1000, True, 0),
    (2000, True, 200),
    (3000, True, 300),
    (9000, True, 500),
    (3000, False, 0),
    (2009, True, 200),
]
for subtotal, active, expected in cases:
    assert discount_cents(subtotal, active) == expected

for invalid in (-1, 1.5, True):
    try:
        discount_cents(invalid, True)
    except ValueError:
        pass
    else:
        raise AssertionError(f"accepted invalid subtotal: {invalid!r}")

print("6 discount cases and 3 invalid inputs passed")

Expected output:

6 discount cases and 3 invalid inputs passed

The 2,009-cent case checks discarded fractional cents. Validation rejects True as a subtotal because Python booleans subclass integers. The precondition for coupon_active is a boolean value; this function does not validate HTTP input. An input adapter must establish that contract.

To reconstruct development, initially retain only the first case, implement zero and add the second. Watch the expectation of 200 fail before introducing eligibility and calculation. Then add the cap, activation, fractions and invalid inputs, one behavior at a time. The complete block already passes; on its own, it cannot establish that your process followed TDD.

Tests provide feedback about design

The calculation needs a subtotal and activation state, not a persisted cart or payment client. This boundary makes testing inexpensive and the contract readable. If calculating a discount requires creating an account, querying inventory and authenticating a session, investigate where commercial decisions became attached to transport details.

That observation does not justify an interface for every operation. The function above needs no mocks, hierarchy or framework. Adding layers without a concrete problem would make the example worse. Design improves when necessary dependencies become explicit and understanding a change requires less work.

Prefer expectations about results to expectations about every internal call. An equivalent calculation should preserve the cases. A genuinely contractual effect order, such as persisting a reservation before publishing confirmation, deserves its own test and an explanation of why the order matters.

Why green tests do not prove the product is right

A misunderstanding shared by implementation and expectation may go unnoticed. If marketing intends a 2,500-cent threshold and you write 2,000 on both sides, the suite stays green. Examples approved by someone who understands the promotion provide a different check from consistency between your own artifacts.

The exercise also ignores concurrency. Two orders might try consuming a coupon's final available use simultaneously. A pure function protects no counter, transaction or uniqueness constraint. A discount unit test must coexist with tests of consumption policy and evidence about how storage resolves the race.

Integrations add their own boundaries: a provider may round differently or reject a combination of discounts. Contract and integration tests must observe those agreements. Reading Beck helps identify the next behavior, but it cannot replace security experiments, failure analysis or validation with users.

Strengths and limitations

The strength is making small decisions open to discussion. You can ask why a particular test comes next, why generalization happens now or why an abstraction should wait. For paired study, this visibility offers more than debating TDD as a personal preference.

The examples have deliberately bounded scope. They do not include negotiating an ambiguous rule across several teams or making an old system testable. A reader expecting a recipe that automatically discovers good architecture may become overconfident. Choosing the testing boundary still requires knowledge of the system.

The pace also needs adaptation. Mechanically reproducing every step can feel slow without transferring learning to a project. The useful exercise is explaining when to reduce step size and when a direct implementation suffices. Test count and execution frequency cannot compensate for weak expectations or a poorly chosen boundary.

Who should read it and what to read alongside it

I recommend the book to developers familiar with functions or objects who have already written assertions. Beginners can study it alongside small exercises, but need not learn programming, modeling and testing tools simultaneously. Someone struggling to execute a function independently can establish that foundation first.

For an unprotected codebase, Working Effectively with Legacy Code helps find an observable entry point. Its characterization tests discover existing behavior; our coupon starts with desired expectations. Confusing these goals encourages copying current results as though they were new requirements.

Refactoring complements improving structure while preserving behavior. If your team's suite is slow or unstable, reserve effort for the feedback environment. Reading Beck will not accelerate remote queries or repair shared fixtures.

A practice plan and verdict

Use a short session to reconstruct the coupon and record the order of cases. In another session, raise the minimum from 2,000 to 2,500 cents. The case (2000, True, 200) should detect the implementation change before its expectation is deliberately updated to zero. Add cases for 2,499 and 2,500, specifying their results under the new rule. Observe whether the change forces you to rebuild unnecessary dependencies.

Then apply the cycle to a small work-related rule with a colleague reviewing. Record domain questions discovered, structural edits and checks remaining outside local tests. Evaluate those decisions without inventing productivity targets based on a teaching exercise.

I recommend the book for learning to turn uncertainty into a concrete next check. Its expected return is control over decision size and available evidence. You have used the reading well when you can select a case that clarifies the contract and explain, even with a green suite, which risks remain open.