Why do teams put component-test provider wiring behind one shared mount helper, and what must each test still control?

## The duplication that justifies a helper A component test's first ten lines are usually not about the component. They are the provider stack: locale, formatting, session, a router, an external store, a data client. That stack is a near-copy of how the application composes itself at its root. Copied into every test file it has two costs: it is written wrong occasionally, and it drifts — the app adds a provider and hundreds of tests keep mounting a tree shaped like last quarter's application. Centralising the wiring in one mount helper fixes both: there is a single place that mirrors the app's composition and a single place to update. ## The dividing line **The helper owns the shape of the environment. The test owns its values.** | Belongs in the helper | Belongs in the test | |---|---| | Which providers wrap the tree, and their nesting order | The starting URL for this case | | Creating a fresh store, router and cache per call | The state to seed the store with | | Sensible defaults for values the case does not care about | The cached entries or canned responses the case needs | | Returning handles the test needs to drive and inspect the tree | Which collaborators are real and which are stand-ins | | Teardown / unmount registration | Every assertion | A helper that bakes in a signed-in administrator and a populated store looks convenient until a test needs the signed-out empty case and has to fight the helper. Defaults are fine; *fixed* values are not. ## Options, not variants Express the per-case knobs as options on one helper rather than as a family of near-identical helpers: - an initial location, so the tree renders as if the user arrived at that URL; - an initial store state, merged over the store's own defaults; - prewarmed cache entries, so the tree can render loaded output immediately; - collaborator overrides, so a case can swap one dependency without restating the stack. When a test needs a provider the helper does not wrap, the answer is usually to add the option, not to bypass the helper — a bypassed helper is how two mounting styles end up coexisting in one suite. ## Freshness is the load-bearing rule 1. Every call builds new provider instances and new state containers. 2. Nothing the helper creates is held in a variable at module scope. 3. The helper registers its own teardown so the tree is unmounted and subscriptions released after each case. Break rule 1 or 2 and the helper stops being a convenience and becomes shared mutable setup: tests pass individually, the suite fails, and the failures move when the order changes. That symptom is usually blamed on the framework and is almost always the helper. ## What a helper cannot buy you A shared helper makes the environment consistent; it does not make it *honest*. If it wires stand-ins for collaborators the feature genuinely depends on, every test inherits that fidelity gap silently, and nobody reading a test file can see it. Two habits keep it visible: keep the helper small enough to read in one screen, and make anything surprising — a faked data layer, a bypassed permission check — an explicit option a test opts into rather than a default it inherits. There is also a readability cost worth naming. A test that hand-wires its providers is verbose but complete; a test that calls a helper is short but its environment is somewhere else. Teams pay that willingly because the environment is the same in every test *and* the helper is stable — if the helper changes weekly, the trade stops paying. ## Interview framing When asked about this, do not stop at "to avoid repetition". Say what the helper is mirroring (the application's own root composition), name the split between shape and values, and volunteer the failure mode — shared instances leaking between tests — because that is the part a candidate who has only read about the pattern will not have. ## A smell worth naming When the helper starts accreting arguments for combinations rather than for values — one for the administrator case, one for the offline case, one for the partially loaded case — it has stopped describing the environment and started encoding tests. Push those back into the tests as seeded state and explicit collaborator overrides, and keep the helper's own surface to the four or five knobs every case reasons about. A helper you can read in one screen is a helper people trust; a helper with a dozen interacting flags is one people copy around and fork.