How does an active test profile make a booted application resolve a fake dependency instead of the real one?

## What a profile is A **profile** is a named mode a run can be started in — conceptually a label attached to the process, chosen by the harness, an environment value, or a declaration on the test class. On its own a profile does nothing. Its power comes from registrations and settings being **conditioned** on it. Two distinct levers hang off that condition, and mixing them up is the usual source of confusion: | lever | what changes | typical use | |---|---|---| | conditioned registration | which implementation is a candidate for a boundary | bind a boundary to a fake that answers in process | | conditioned settings | the values the same implementation reads | point the real client at a disposable instance started for the run | The first swaps the *implementation*; the second swaps the *target*. A suite usually needs both: an in-process fake for the dependency you cannot start, and a real client aimed at a throwaway instance for the one you can. ## How the winner is chosen Once more than one registration could satisfy a boundary, something has to decide. The shapes seen across frameworks are: - **Mutual exclusion.** The real registration is conditioned to be absent under the test profile, so there is only ever one candidate. This is the least surprising arrangement and the one to prefer. - **Explicit beats defaulted.** A registration marked as a fallback yields to any other candidate; the fake is simply a non-fallback candidate. - **Specific beats general.** A candidate qualified by a profile outranks one that applies unconditionally. - **Last contribution wins.** The set is merged in a defined order and later sources replace earlier ones. - **Ambiguity is an error.** With two equal candidates and no rule to separate them, the container refuses to build and reports the conflict at startup. That last row is a feature, not an obstacle: a loud failure at boot is far better than a graph that silently chose the production implementation for a test run. ## The failure modes worth naming 1. **The profile was never activated.** The declaration existed, nothing turned it on for this run, every conditioned registration stayed out, and the default graph was built. The test then exercises the real dependency — slowly, or destructively — while appearing to pass. 2. **Both candidates stayed eligible.** Either the boot fails with an ambiguity, or a precedence rule nobody remembers resolves it, and which one it picked is not visible from the test. 3. **Half a swap.** The implementation was replaced but the settings still name the production target, or the reverse: the real implementation reads test settings and points somewhere harmless while the test believes it is talking to a fake. 4. **Profile creep.** The test profile accumulates registrations over years until it is a second application that resembles production only loosely, and a boot under it proves little about a boot under production settings. ## Making the choice visible Because every one of those failures is silent from inside a passing test, worthwhile suites make the wiring observable: - assert, once, that the boundary resolved to the type the run intended — a cheap canary that fails loudly when a profile stops being activated; - log or assert the active profile at the start of a run, so "which mode was this?" is answerable after the fact; - prefer mutual exclusion over precedence, so the question never needs a rule to settle it; - keep one high-fidelity tier that boots without the test profile at all, so the production arrangement is exercised somewhere. ## Keeping the two modes comparable A mode earns its keep only while the test arrangement stays a small, readable delta from the production one. Write conditioned registrations next to the ones they displace rather than in a distant file, keep the count small enough to read in one sitting, and re-examine long-lived entries: a fake added because a dependency was once slow may now be standing in for something perfectly cheap to start for real. The delta is the artefact to review, not the individual entry. ## What interviewers listen for The weak answer says "we set a profile and it uses the fake" and stops — a description of the outcome that never explains the selection. The answer they want names the mechanism (registrations conditioned on a named mode), separates swapping the implementation from re-pointing the settings, and volunteers the failure mode: if the profile is not actually active, the default wins and the test quietly runs against the real thing.