How do you decide whether a unit test may exercise real collaborators, and what does that choice cost?

## Why this is a leadership decision at all Left to individuals, the boundary drifts. One team substitutes every collaborator by reflex; another instantiates half a module in each test. Both suites still go green, so nothing forces the question — until the bill arrives, either as a refactor that turns two thousand tests red without a single behaviour changing, or as a suite that has quietly grown past the point where anyone runs it before pushing. Both are boundary decisions cashing in late, which is why the choice belongs in a written default rather than in taste. ## The two styles, stated as costs **Narrow.** The boundary is one type; everything it reaches for is substituted. Benefits: a failure implicates exactly one type, and the tests run as fast as anything can. Costs: the test knows the collaboration structure, so any behaviour-preserving change to that structure is a test-editing project. A team in this mode eventually reports that 'refactoring is expensive here', and the suite is why. **Wider.** The boundary is a cohesive behaviour, with in-process, deterministic collaborators left real. Benefits: the tests assert on promises rather than arrangements, so internal reshaping is free, and the tests double as usable documentation of the behaviour. Costs: a failure names a region, so triage takes longer; setup gets larger as the boundary grows; and the temptation to keep widening it — one more real collaborator, and one more — is how a fast suite becomes a slow one without any single decision to blame. The useful framing is that you are choosing between two kinds of maintenance: **triage cost per failure** versus **edit cost per refactor**. Neither is free, and which one dominates depends on how volatile the code's internal structure is. Volatile internals argue for the wider boundary; stable internals with intricate logic argue for the narrower one. ## The default I would write down 1. Substitute at the **process edge** — the clock, the filesystem, the network, another thread, anything shared. This is non-negotiable, because these buy nondeterminism or milliseconds-to-seconds, and the level cannot afford either. 2. Keep real anything **in-process, deterministic and cheap**. A value object, a calculation, a small mapper — replacing these adds test code and removes coverage without buying speed. 3. Where the two rules conflict — an in-process collaborator that is genuinely expensive to build, or one so large that failures stop localising — the decision is documented per module rather than argued per pull request. 4. Any deviation is a comment in the test or a line in the module's notes. The point is not bureaucracy; it is that the next person can see the choice was made. ## Speed as the constraint that decides ties The budget deserves a number, because arguments about boundaries end quickly once someone times the suite. On a renewal codebase I would want a figure of the shape: 14,200 narrow tests finishing in 6 minutes 40 seconds is already past the useful threshold — the suite is no longer in the edit loop, and its feedback arrives after attention has moved. Under a minute keeps it in the loop; a few seconds keeps it in the keystroke loop. So I ratchet: record the wall-clock time, fail the build if it regresses beyond a margin, and treat a boundary choice that spends seconds as a proposal with a cost attached. This also disciplines the wider style, whose failure mode is exactly incremental slowdown that nobody owns. A related discipline: measure the **slowest** tests, not the average. Slow suites are usually a small tail — a handful of cases that quietly cross the process edge — and the tail is where a boundary violation hides. ## What I would not use to justify the policy The familiar claim that a defect costs an order of magnitude more to fix at each later phase is genuinely contested — the underlying studies are old, the conditions are not those of continuous delivery, and the multiplier is cited far more confidently than the evidence supports. I would not build a policy argument on it. The defensible argument is the one you can measure locally: how long triage takes per failure, how often a behaviour-preserving refactor forces test edits, and how long the suite takes. Those are observable in your own repository this quarter. ## How I would roll it out Not as a rewrite. New tests follow the default; existing tests are migrated only when they are already being touched, or when a specific pain — a refactor blocked by a wall of red, a module whose failures never localise — pays for the change. I would ask for two signals in review: does a failure in this test tell the reader where to look, and does this test have any reason to break other than the behaviour changing? A suite that answers yes and no respectively, inside the time budget, has its boundary in the right place, whatever style the team calls it.