In Playwright, how do you override the built-in page fixture without losing the original?

## Overriding is by name, not by wrapping There is no special API for replacing a built-in. You define a fixture whose **key matches the name of an existing fixture**, and from then on any test that resolves that name through your extended `test` object gets your version: ```typescript import { test as base } from '@playwright/test'; export const test = base.extend({ page: async ({ page }, use) => { // configure the incoming page await use(page); // undo it }, }); ``` Naming the fixture `adminPage` instead would **add** a fixture rather than override one, and tests asking for `page` would still get the untouched built-in. ## The base value arrives in the dependencies The `page` destructured in the first argument looks recursive and is not. When Playwright resolves a fixture's dependency by the same name as the fixture itself, it supplies **the value from the definition being overridden** — the built-in here, or the previous override in a chain. That is what makes an override a wrapper instead of a replacement: 1. The base definition runs and produces its value. 2. Your override receives it, does its own setup on it, and calls `await use(...)`. 3. Your teardown lines run first, then the base definition's teardown. ## Add versus override | | New fixture | Override | |---|---|---| | Key in `test.extend` | a name nobody uses yet | the exact name of an existing fixture | | Opt in per test | yes — only tests that name it | no — it applies to every test using that name | | Base value available | only if you destructure it by its own name | yes, under the same name | | Blast radius | the tests that ask for it | every file importing this `test` object | ## Hand back the same value, or hand back your own Most overrides call `await use(page)` with the object they were given, because the point is to *configure* it: install a route stub, set a default state, seed the console with a known signed-in role. You may also provide a different value entirely — a wrapper object, for instance — but then every test using that name gets your type, and the built-in one is gone from their reach. Points worth keeping in mind: - **Undo what you install.** Anything the override sets up on the incoming value belongs in the teardown half, below `use`. - **Keep it cheap.** Every test in every file that imports this `test` pays for the override, including tests that would rather not have it. - **Keep it unsurprising.** A `page` that silently navigates somewhere makes every test in the suite start from a place its own code never mentions. - **It is not declinable.** A test cannot ask for the un-overridden version; if some tests must opt out, add a separate opt-in fixture instead of overriding. ## Overriding an option fixture The same by-name rule covers configuration fixtures, not just objects. Overriding `storageState` in `test.extend` changes which saved session the contexts of those tests start from, in exactly the way overriding `page` changes which page they get. The mechanic is identical: same key, value provided through `use`. ## Chained extends stack `base.extend(A).extend(B)` produces one `test` whose `page` is B's, and B's `page` dependency is A's `page`, whose dependency is the built-in. Setup runs outermost-last (built-in, then A, then B); teardown unwinds in the reverse direction. That is what lets one package add tracing-ish instrumentation and another add a routing stub without either knowing about the other. ## In an internal admin console A useful override for a console with several staff roles is one that stubs the feature-flag endpoint so every test starts from a known flag set, then removes the route afterwards. It applies to the whole suite, costs one route registration per test, and does not change what any test's own code says.