How would you structure shared Playwright route stubs so individual tests can still override one endpoint?

## The mechanism the design rests on Everything here follows from one rule: when several handlers match a request, Playwright consults page-scoped handlers before context-scoped ones, and within a scope the most recently registered handler first. Nothing ranks patterns by specificity. That gives you a layering primitive for free — a broad default registered early is overridden by a narrow stub registered later, and by any page-scoped stub at all. ## Where the baseline lives Put the shared stubs in an **auto fixture** so no test has to remember to call anything: ```ts export const test = base.extend<{ networkBaseline: void }>({ networkBaseline: [async ({ context }, use) => { await context.route('**/api.weather.example/**', route => route.abort('blockedbyclient')); await context.route('**/v1/forecast*', route => route.fulfill({ json: { tempC: 21 } })); await use(); }, { auto: true }], }); ``` Two properties make this work. It is on the **context**, so per-test `page.route()` overrides outrank it by scope rather than by luck of ordering. And it is **auto**, so every test in the project starts from the same known network baseline instead of an ad-hoc mix of stubbed and live traffic. ## Ordering inside the baseline The deny-all goes **first** and the specific stubs after it, because later registrations are consulted first. Get that backwards and the deny-all shadows every stub you wrote below it — the failure mode looks like "all my stubs stopped working", with no error to explain it. | Registered | Consulted | Effect | |---|---|---| | deny-all for the host, then the forecast stub | forecast stub first | endpoint stubbed, everything else on that host blocked | | forecast stub, then deny-all for the host | deny-all first | every request blocked, including the stubbed endpoint | ## How a test overrides A test that needs different data registers `page.route()` for that one endpoint in its own body. It wins on scope, it does not unregister anything, and it disappears with the page at the end of the test. Three things keep that clean: - **Share the pattern, not a copy of it.** Export the URL pattern from one module so the default and the override are the same string and a rename cannot desynchronise them. - **Override the endpoint, not the fixture.** Adding a payload parameter to the baseline fixture makes every test carry a knob it does not use; a local `page.route()` keeps the special case local. - **Do not reach for `unroute`.** Removing the default in order to replace it is a bigger, order-sensitive change than simply registering a handler that outranks it. ## The costs you are accepting - **Invisible setup.** Someone debugging a failing test sees traffic answered by code they never opened. Name the fixture for what it does and keep it in a path the spec already imports. - **Silent blocking.** A deny-all that aborts without a word turns a missing stub into a confusing render failure. Log the blocked URL before aborting. - **Baseline drift.** Once every test depends on one payload, changing it becomes a cross-suite edit; keep the default minimal and let tests state the fields they actually assert on. - **Over-broad matching.** A baseline pattern wide enough to be convenient will eventually swallow an endpoint someone meant to exercise for real. ## Conventions worth writing down 1. One module owns the URL patterns; nothing else writes a route string literal. 2. Defaults are registered on the context in an auto fixture; overrides are registered on the page inside the test. 3. Broad handlers are registered before narrow ones, and any catch-all either logs and falls back or blocks loudly. 4. A project that is meant to talk to a real service opts out of the baseline explicitly, rather than being covered by it silently. ## The judgment call The real decision is how much of the network the default layer owns. A thin baseline — block the third-party host, stub the one endpoint every page needs — keeps tests readable and failures attributable. A thick one buys determinism at the cost of a suite whose behaviour lives somewhere nobody reads. Scope it to a project, review it like production code, and revisit it whenever a test's failure output stops explaining itself.