How do you stop test-only wiring from quietly becoming a second application configuration that no longer matches production?

## The failure this prevents Replacements accumulate one reasonable decision at a time. A dependency is slow, so it gets a stand-in. A component is awkward at startup, so it is bound to a no-op. A setting is inconvenient, so the test mode overrides it. Each step is defensible, and after two years the application the suite boots shares a name with production and not much else. Nothing fails; the suite is green and fast, which is exactly why nobody revisits it. The cost is specific and worth naming precisely: **the evidence removed is everything that only exists when the real arrangement is assembled**. Namely - whether every dependency in the graph can actually be satisfied; - whether two candidates for one boundary would be ambiguous; - whether construction-time work succeeds against a real target — a pool opening, a value read and cached, a listener subscribing; - whether the settings the deployment supplies are the ones the components read; - whether the real implementation of a boundary honours the contract the stand-in was written to imitate. A suite that replaces liberally cannot fail for any of those reasons, so it stops reporting them. ## Running it as a budget | lever | what it does | what it costs | |---|---|---| | a small set of named wirings, owned | keeps the arrangements countable and reviewable | some tests carry replacements they do not need | | review each addition as configuration | makes the lost evidence explicit at the moment it is lost | slows down adding a test that needs new wiring | | a tier that boots unmodified | restores the startup-fault evidence | the slowest tier, and needs disposable dependencies | | a visible count of replacements | turns drift into a number someone owns | only works if someone actually looks | The judgment call is where to sit on that table, and it differs by system: a service with two out-of-process dependencies can afford to boot unmodified often, while one with a dozen cannot, and should concentrate its unmodified boots on a handful of paths that carry the most risk. ## The design signal The most useful reframing to bring to this discussion is that **a long replacement list is usually a statement about the application, not about the tests**. When a graph cannot start without a stand-in for five collaborators, the cause is generally one of: 1. components doing remote work during construction rather than on first use; 2. a boundary defined in the vendor's shape rather than the shape the application needs, so nothing cheap can stand in for it; 3. a module that starts everything or nothing, with no seam for a narrower slice; 4. configuration that is read at construction time from a source only a deployment provides. Each of those is fixable in the application, and each fix removes replacements from every test at once. A team that only ever fixes these in test configuration is paying rent forever on a defect it could buy out. ## What the policy looks like in practice - **Name and own the wirings.** Not "whatever this test class happens to declare" but a short list with a stated purpose each, reviewed like production configuration. - **Keep an unmodified boot in the pipeline.** Even a handful of paths, run per merge, catches unsatisfied and ambiguous dependencies before a deployment does. - **Make the replacement count visible.** A number in review beats an annual audit that never happens. - **Re-examine long-lived replacements periodically.** A stand-in added because a dependency was slow three years ago may now be replacing something cheap. - **Say what each wiring stops proving.** One sentence per wiring is enough, and it is the artefact that makes the tradeoff reviewable by someone who did not write it. ## What interviewers listen for This is a judgment question with no single right answer, and the failure modes are the two extremes. "Replace everything, tests must be fast" gives up the evidence the suite exists to produce. "Never replace anything" produces a suite nobody runs, which produces no evidence at all. What distinguishes a strong answer is naming the specific evidence each replacement removes, holding at least one place in the pipeline where the real arrangement is assembled, and treating a growing list as a prompt to change the application rather than the test configuration.