A custom hook you want to test reads from a context provider that your test does not render, so it throws the moment `renderHook` runs it. What are your options, and what does the amount of setup tell you?

## Why it throws A hook that reads context is not self-contained: it is a function of state that lives above it in the tree. In the app that state is always there, because the provider is mounted at the root. In a test the stub component that `renderHook` creates is mounted alone, with nothing above it, so a hook that reads a required context gets whatever default the context was created with — often `undefined`, and well-written hooks throw a deliberate error saying they must be used inside their provider. That error is a feature. It is telling you something true about the unit you are trying to isolate: it cannot be isolated without supplying its environment. ## Option 1 — wrap it in the real provider The `wrapper` option takes a component that receives `children` and renders them; the harness mounts your stub inside it. ```jsx const wrapper = ({ children }) => ( <SettingsProvider value={{ currency: 'EUR' }}>{children}</SettingsProvider> ); const { result } = renderHook(() => useCurrencyFormatter(), { wrapper }); ``` This keeps the real provider in the loop, so the test breaks if the provider's value shape and the hook's expectations drift apart — which is one of the few genuinely useful things this test can catch. Prefer providers that let you inject a value directly; when the only way in is a provider that fetches its own data, the provider itself is the thing that needs redesigning. ## Option 2 — test through a component If a real consumer of the hook already renders inside that provider tree, testing the consumer costs nothing extra and covers strictly more: the hook, the provider wiring, and the component that reads the result. This is usually the better trade for an app hook that has one caller and is inseparable from its context anyway. ## Option 3 — change the hook The most valuable outcome of a painful test is often a change to the code under test. A hook that takes what it needs as an argument — `useCurrencyFormatter(currency)` — is testable with no wrapper at all, and the context read moves to the one component that actually sits under the provider. Not every hook should be reshaped this way; a hook whose whole purpose is to expose context is doing exactly its job. But a hook that reaches into three ambient providers to do a computation is hiding its inputs, and the test is the first place that shows up. ## What not to do **Do not stub the context module.** Replacing the module so the hook receives a fake removes the only participant that could have disagreed with it. The test then asserts that the hook works against a value the test itself invented, and it will stay green through a provider refactor that breaks production. **Do not build a wrapper that recreates the app.** When the wrapper stacks a router, a data-fetching client, an auth provider, a feature-flag provider and a theme, several things have gone wrong at once: the setup is now longer and more likely to be wrong than the assertion; every one of those providers is a shared mutable dependency that must be reset between tests or the suite develops order dependence; and the label "unit test" has stopped being accurate without anyone deciding to make it an integration test. At that point choose deliberately — either accept it as an integration test of the real component, or reduce the hook's dependencies. **Do not let the shared helper hide it.** Most codebases grow a single `renderWithProviders` used everywhere. That is reasonable for a small number of genuinely global providers, and it stops each test from re-deriving the tree. The failure mode is that it also stops anyone from noticing that a hook now needs five providers, because the cost is paid once in a file nobody reads. Reviewing what goes into that helper is how a team keeps the signal. ## The transferable principle Ambient dependencies are the thing that decides where a test seam can go. A unit that reads its inputs from arguments can be tested anywhere; a unit that reads them from its surroundings can only be tested by reconstructing those surroundings, and the reconstruction is itself code that can be wrong. When a test's setup dwarfs its assertion, treat that as design feedback about the unit rather than as a fact of life about testing.