In a framework-booted test, how do you make the application resolve a stand-in collaborator instead of the real one?

## What a wiring override actually replaces A framework-managed application is assembled from **registrations**: statements of the form "for this boundary, use this implementation, with this lifetime". At startup a container reads the registrations and builds an **object graph** — request handlers, the middleware chain, scheduled and background components — resolving every dependency each of them declares. The important consequence for testing is that your test does not construct the handler. The framework does. Setting a field on an object you made yourself has no path to the object the router will invoke. The only leverage a test has over what that handler collaborates with is the set of registrations the container reads before it builds anything. A **wiring override** is an amendment to that set: the test contributes a registration for the same boundary that points at a stand-in, and the graph is built from the amended set. Everything resolved from that graph receives the stand-in — the handler, a middleware that depends on the same boundary, a component started at boot — because they all resolve from the same registrations. ## How the three common techniques differ | technique | who sees the stand-in | works for a framework-built handler | main risk | |---|---|---|---| | construct the object under test yourself and pass the stand-in in | only that one instance | no | the graph that actually serves the test's requests is untouched | | contribute a replacement registration before the graph is built | everything resolved from that graph | yes | the replacement reaches other tests that share the graph | | mutate the registry after the application has started | later lookups only, if the framework re-resolves | partly, and unpredictably | consumers already holding a reference keep the real collaborator | The middle row is what "overriding wiring" means, and the other two are the mistakes it is usually contrasted with. ## Where the replacement is declared The declaration takes a few recognisable shapes, and frameworks differ over which they offer: - **Test-local configuration** merged over the application's own, adding or replacing one registration. - **A wiring module the test class names**, holding the stand-ins that whole group of tests wants. - **A per-test declaration the harness reads** and turns into an amendment before it boots. - **A registration conditioned on an active test profile**, so the real one is simply not a candidate for that run. All of these share one property: the harness reads them **before** it asks the container to build the graph. That ordering is the whole mechanism, not an implementation detail — a registration that arrives after the graph exists has missed its moment for anything already constructed. ## What an override does not change It is easy to over-read what a swap buys you: - Registrations you did not touch still run, so work other components do at startup still happens. - The routing table, the middleware order and the settings the application read stay exactly as the booted configuration says. - If nothing on the exercised path depends on the boundary you replaced, the override changes nothing and the test still passes — for the wrong reason. Assert that the stand-in was actually reached, not merely that the response was 200. - Lifetime is part of a registration. Replacing a per-request implementation with one shared object changes how many instances exist, and any state the stand-in accumulates now spans requests. ## A check worth running once After wiring a replacement, prove it landed before trusting anything else the test reports: resolve the boundary and assert on the object you got back, or assert that the stand-in recorded the call you expected. Two minutes there save an afternoon spent debugging a test that was exercising the real collaborator the whole time, and that assertion is the one that fails first when somebody later moves the registration into configuration this test no longer reads. ## What interviewers listen for The answer they want is "I change what the container resolves, before it resolves it". Candidates who have only written tests that call a function directly tend to reach for constructing the collaborator themselves and are surprised that the request still hit the real dependency; candidates who have only ever copied a test template tend to describe the syntax without being able to say what it amends. Saying the mechanism — registrations in, graph out, so amend the input — covers every framework's spelling of it and is what makes the follow-ups (when it must happen, how long it lasts, who else sees it) answerable.