Test Doubles: Isolation and What It Costs

A function worth testing usually depends on something inconvenient: a database, a payment provider, the system clock, a queue, another team's service. Running the real thing in a unit test is often impossible and always slow.

A test double is any stand-in for a real collaborator. The four honest reasons to reach for one:

• Speed. In-memory beats a network round trip by three or four orders of magnitude, and that ratio is what makes the pyramid's base affordable.
• Determinism. Real clocks, real randomness and real networks make tests that fail for reasons unrelated to the code.
• Unreachable states. "The payment provider times out after charging the card" is a state you cannot conjure on demand, and it is exactly the state whose handling you need to verify.
• Isolation of blame. When the test fails, the failure is in the unit, not somewhere down a chain of six real components.

Key idea: every double trades fidelity for control. You get a fast deterministic test, and in exchange the test no longer knows whether your assumptions about the real collaborator are true. Everything that goes wrong in this lesson is that trade, taken without noticing.

The vocabulary comes from Gerard Meszaros' xUnit Test Patterns, and teams use it loosely, but the categories are genuinely different tools.

The distinction that actually changes outcomes is not five-way. It is whether the double is used for state verification (run the code, then check the resulting values) or behaviour verification (assert that specific calls happened, in a specific way).

Stubs and fakes support state verification: they let the code run and you check what came out. Mocks and spies invite behaviour verification: you assert on the conversation between objects. The first survives refactoring. The second is coupled to the current design by construction, and that is the whole of the next two steps.

Concretely, here is one behaviour verified twice: a service that records an order and emails a receipt.

# Mock-heavy: asserts the conversation
def test_places_order_with_mocks():
    repo, mailer = Mock(), Mock()
    service = OrderService(repo, mailer)
    service.place(order)
    repo.save.assert_called_once_with(order)
    mailer.send.assert_called_once_with(order.email, "receipt")

# Fake-based: asserts the outcome
def test_places_order_with_fakes():
    repo, mailer = InMemoryOrders(), RecordingMailer()
    service = OrderService(repo, mailer)
    service.place(order)
    assert repo.get(order.id).status == "placed"
    assert mailer.last_to == order.email

The first pins the mechanism: two named methods, called once each, with those arguments. Rename save to persist, batch the two writes, or move the email behind a queue, and it fails though behaviour is unchanged.

The second pins the outcome: the order is retrievable and placed, the customer was mailed. Every one of those refactors passes untouched, and a genuine regression, an order that never gets saved, still fails it.

In practice: the fakes cost more to write once and less to own forever. That is usually the right trade for a collaborator you own and use in many tests.

The deeper problem with doubles is not brittleness. It is that a double encodes your beliefs about the real thing, and beliefs can be wrong.

The defences are structural, not cleverer mocking:

• At least one test against the real thing, even if it is slow and runs only in CI: a sandbox account, a contract test, a nightly smoke test.
• Record and replay, where a real interaction is captured once and replayed, so the fixture derives from reality instead of imagination.
• Contract tests, where the provider runs the consumer's expectations against itself, so drift breaks the provider's build rather than the consumer's production.

The second failure is slower and more common. Mock-heavy tests make a codebase expensive to change, and the mechanism is worth stating precisely: a mock-based test is a second, executable copy of the design. Change the design and you must change both.

The symptoms are recognisable from any codebase that has been through it:

• A behaviour-preserving refactor turns dozens of tests red, and "fixing" them means rewriting the assertions to match the new call graph.
• Test setup grows longer than the code under test, because each mock needs its return values configured.
• Developers stop refactoring, not from discipline but from cost, and design decay becomes structural.

Gotcha: the rule of thumb with the best track record is do not mock what you do not own. A double for a third-party client freezes your guess about someone else's API, and you will not be told when it changes. Wrap the third party in a thin adapter you do own, test the adapter against the real thing, and let the rest of your code depend on your interface, which you are allowed to have opinions about.

There is a real school of thought on the other side, and it is worth understanding rather than dismissing.

The disagreement has names. The London school, sometimes called mockist, tests each unit in strict isolation with all collaborators doubled, and uses the tests to drive the design of the interfaces between objects. The Chicago or classicist school prefers real collaborators wherever they are cheap, doubling only at the awkward edges, and verifies state rather than conversation.

Both are coherent. The London style gives sharper failure localisation, since only one real object can be at fault, and it exerts genuine design pressure: painful mock setup is a signal that a class has too many collaborators. Its cost is the coupling this lesson has been about. The Chicago style gives tests that survive refactoring and catch integration mistakes between your own classes for free, and its cost is that a failure may implicate several objects at once.

A workable default, and the one most teams converge on with experience: use real objects inside your own module boundary, fakes for the things you own but are inconvenient (repositories, clock, queue), and mocks only at the true edges where you are asserting a protocol, such as "a receipt was requested exactly once".

Two specific fakes are worth building early in almost any system, because they remove whole categories of flaky and untestable code.

A fake clock. Code that calls now() directly is untestable at boundaries: expiry, retry backoff, rate limits, anything seasonal. Inject a clock and time becomes an input you control.

class FakeClock:
    def __init__(self, t): self.t = t
    def now(self): return self.t
    def advance(self, seconds): self.t += timedelta(seconds=seconds)

def test_token_expires_after_one_hour():
    clock = FakeClock(datetime(2026, 1, 1, 12, 0))
    token = issue_token(clock)
    clock.advance(3601)
    assert not token.is_valid(clock.now())

Without it, that test either sleeps for an hour or reaches inside the implementation to fake expiry, and the second option verifies nothing.

An in-memory repository. One fake implementing your storage interface, shared across the suite, turns hundreds of database-touching tests into millisecond tests. The discipline that makes it safe is running the same test suite against both the fake and the real implementation, so the fake is proven to honour the contract rather than merely being convenient.

That pattern, one interface with two implementations verified by a shared suite, is the cleanest answer to this lesson's central tension: full speed in the common case, real evidence that the double does not lie.

The last thing to take from test doubles is diagnostic rather than technical: difficulty in testing is usually information about the code, not about testing.

Recurring signals and what they mean:

• This test needs eight mocks. The unit has eight collaborators. That is a design problem the test is reporting accurately.
• I must mock a private method or patch an import. The dependency is hidden inside the unit instead of being passed in. Making it an argument fixes both the test and the coupling.
• The fake keeps growing logic. Real behaviour is leaking into it. Either the interface is too broad, or that logic belongs in code you can test directly.
• Every test needs the same twenty lines of setup. There is a missing abstraction, and the tests found it before the code did.

Key idea: testability is a property of design, not an activity performed on finished code. Code that is hard to test in isolation is usually code whose dependencies are implicit, and the fix that makes it testable, passing dependencies in rather than reaching out for them, is the same fix that makes it reusable and comprehensible.

With design and isolation covered, the next lesson changes the question entirely. Everything so far assumes you can think of the cases worth testing. Property-based testing is what you do when you cannot.