Test doubles: London vs Detroit, and the over-mocking trap

A team mocks everything. Every collaborator in every unit test is a mock with expect(...).toHaveBeenCalledWith(...). Their suite is 2,400 tests, all green, 91% coverage. Then a refactor that splits one service into two — pure internal reorganization, identical behavior — turns 600 tests red in a single afternoon. None of them caught a bug; they caught the fact that the internal calls moved. Worse, a month earlier a real pricing bug shipped to production with the suite fully green, because the mocks returned canned values and nobody had asserted the actual computed total. The suite was measuring the wrong thing the whole time.

Five kinds of double, and the one that bites

“Mock” gets used as a catch-all, but xUnit Test Patterns names five distinct test doubles, and the distinction decides whether your test is robust or brittle. A dummy is a placeholder passed but never used. A stub returns canned answers to calls — it feeds state in. A fake is a working lightweight implementation (an in-memory repository standing in for Postgres). A spy records how it was called so you can inspect it after. A mock is pre-programmed with expectations: it asserts that specific calls happened, in a specific way, and fails the test if they didn’t.

The first four feed inputs or observe outputs; the mock is the one that asserts interactions, and that is where brittleness comes from. A mock bakes the production code’s call structure into the test’s pass/fail condition. The moment you change how the code achieves a result — even with identical observable behavior — the mock’s expectations no longer match and the test fails. Stubs and fakes don’t do this; they just supply data and let you assert the final state. Reaching for a mock when a stub would do is the single most common way teams manufacture fragile tests.

London (mockist) vs Detroit (classicist)

The two schools are a real, named disagreement. The London / mockist school works outside-in: a unit is one class, you mock all its collaborators, and you test by asserting the interactions between objects — the right messages were sent in the right order. The Detroit / classicist (also Chicago) school works inside-out: a unit is a behavior that may span several real objects, you use real collaborators wherever you can, mock only what you must, and assert final state rather than calls.

The practical consequence is what survives a refactor. Classicist tests assert outcomes, so they afford ruthless refactoring — you can restructure internals freely and the test stays green as long as the result is right. Mockist tests assert call structure, so they pin the implementation: they catch design intent precisely but break whenever the internal collaboration changes. London’s strength is fast outside-in design feedback and tiny isolated units; its failure mode is exactly the 600-red-tests afternoon — a suite so coupled to structure that refactoring becomes prohibitively expensive.

The boundary rule resolves it

The senior synthesis isn’t “pick a school.” It’s a boundary rule: mock what you can’t run, use real objects for what you can. Mock the things that are slow, nondeterministic, or have side effects you can’t undo — the network, the clock, the payment processor, the email sender, the third-party API. For collaborators you own and that run fast and pure, use the real thing or a fake; asserting final state over real internal objects gives you a test that breaks only when behavior breaks. This is mostly the classicist position with London’s discipline applied at the system edges, and it dissolves the over-mocking trap: you never mock a value object or a pure helper, because there is nothing to isolate from.

The decisive question for any double is: if I refactor internals without changing behavior, should this test fail? If the answer is no, you are using a mock where a stub or a real object belongs. Over-mocking is when that answer is “yes” for tests of code you control — and it is precisely what turns a green suite into 600 red tests that caught no bug, while the real pricing error slipped through because the mocks returned canned numbers no one ever checked against a real computation.