In a test suite using Mock Service Worker (MSW), what happens by default to a request that matches no handler, and why do teams start it with onUnhandledRequest: 'error'?

## The default is permissive on purpose MSW's `onUnhandledRequest` option decides what to do with a request that no handler claimed. The default, `'warn'`, prints a message naming the request and then **performs it as-is** — the request continues to whatever host it was addressed to. That default suits MSW's other use case, browser development mode, where you often mock two endpoints and want the rest of the app to keep working against a real backend. In a test suite that same default is a liability, because a test's job is to be deterministic and self-contained, and a permissive default lets it silently stop being either. ## What goes wrong **The suite acquires a hidden dependency.** A handler path has a typo, the request escapes, and if a real host answers, the test may even pass — against live data, not against a fixture. Now the suite's result depends on a service nobody listed as a dependency of the build. **Failures land far from their cause.** More often nothing answers: the environment has no network, DNS fails, or the request hangs until the test times out. What the report shows is `waitFor` timing out on an element that never appeared, or `undefined is not an object` deep inside a component. The engineer debugs the component; the actual defect is one character in a handler's path. **It flakes by environment.** Passing locally because a VPN reaches staging, failing in CI where it does not, is the classic shape. So is slowness: an unmocked call adds real latency, which is why suites sometimes get mysteriously slower after a feature that added a new network call nobody noticed. **Coverage silently rots.** As the app adds calls, the mock layer stops describing the whole surface. Nothing tells you, because nothing is required to fail. ## Making the mismatch loud ```js server.listen({ onUnhandledRequest: 'error' }) ``` Now an unmatched request throws, MSW names the method and full URL, and the failure lands on the request rather than on a downstream symptom. This is the setting most teams converge on for CI, and its main value is diagnostic: it converts a whole class of confusing failures into one obvious message. The four causes it exposes, in rough order of frequency, are a mistyped path; a relative path such as `/api/users` where the app calls `https://api.example.com/users`; the wrong method on the handler; and a genuinely new request the code added since the fixtures were written — which is exactly the signal you want, because it is a real gap in the mock surface. ## Dealing with the noise The common objection is that strict mode fails on requests you never meant to mock. In jsdom that is usually less dramatic than feared — no images, stylesheets or fonts are fetched — but a framework's own runtime calls, telemetry, or a third-party widget can all show up. The right response is to declare them, not to loosen the policy. Add explicit handlers for the URLs that should reach the network and have their resolver return `passthrough()`: ```js import { http, passthrough } from 'msw' export const server = setupServer( http.get('/assets/*', () => passthrough()), …handlers, ) ``` That keeps strictness for everything else while writing down, in code, exactly which traffic is intentionally unmocked — which is far better documentation than a permissive default. `onUnhandledRequest` also accepts a callback form when you need per-request logic, letting you stay silent for a known pattern and fail for everything else. Reach for that only when a URL pattern cannot express the rule. A related habit: keep the strict policy in the shared setup file rather than per test file, so a new test file cannot silently opt out of it. ## Where 'bypass' belongs The third value, `'bypass'`, performs the request without even warning. It is not a test setting — it is for a browser development worker that intentionally mocks a slice of the API while everything else talks to a live backend. Using it in tests reintroduces every failure mode above and removes the warning that might otherwise have hinted at them. ## The judgment being tested An interviewer asking this is checking whether you treat the mock layer as a boundary that should be *complete and enforced*, or as a convenience that happens to cover the calls you thought of. The senior answer names the default, names the failure modes it produces in CI, chooses strict for tests, and knows the escape hatch is an explicit passthrough for named traffic rather than a blanket relaxation.