In Playwright, in what order do dependent custom fixtures set up and tear down around a test?

## Dependencies are declared by name A custom fixture asks for another fixture with the same syntax a test uses — destructuring the first argument: ```typescript const test = base.extend<Fixtures>({ auditLog: async ({}, use) => { /* ... */ }, adminShell: async ({ page, auditLog }, use) => { /* ... */ }, }); ``` `adminShell` depends on the built-in `page` and on the custom `auditLog`. There is no registration list, no ordering annotation, and no priority number. The dependency graph is derived entirely from the destructured names, plus the names each test, hook and override mentions. A consequence people often get wrong in interviews: **the key order inside `test.extend` means nothing**. Defining `adminShell` above `auditLog` changes nothing about which runs first. Nor does alphabetical order, nor the order of the fixture names in the test's own signature. ## Setup order, then teardown order For the graph above, a test that names `adminShell` produces: 1. `page` is set up (it is a dependency of `adminShell`). 2. `auditLog` runs its setup and reaches `await use(entries)`. 3. `adminShell` runs its setup and reaches `await use(shell)`. 4. The test body runs. 5. `adminShell` resumes and runs the lines after its `use`. 6. `auditLog` resumes and runs the lines after its `use`. 7. `page` is torn down. | Phase | Direction | |---|---| | Setup | dependencies first, dependants after | | Teardown | dependants first, dependencies after | That reverse order is a real guarantee to design against, not a coincidence: **a fixture may still use its dependencies during its own teardown**. A fixture that wrote to `auditLog` during setup can write a closing entry to it after `use`, because `auditLog` cannot be torn down until every fixture that named it is finished. ## What this buys you - **Composition instead of one giant fixture.** A seat-creating fixture, a signed-in-shell fixture and a log fixture can each do one thing and name the others. - **No manual ordering.** Add a dependency name and the order fixes itself; remove one and nothing else has to change. - **Reuse of a single instance.** Two fixtures naming `auditLog` in the same test receive the *same* value; the fixture is set up once per test, not once per consumer. - **A readable graph.** The signature of each fixture is the whole story of what it needs. ## Cycles are an error If `a` names `b` and `b` names `a`, there is no valid order, and Playwright fails the run with a fixture-dependency error rather than guessing. The fix is structural: extract the part they both actually need into a third fixture, and let each depend on that. ## Failure in the middle of the chain If a dependency's setup throws, the fixtures above it in the graph never start — there is nothing of theirs to tear down. Fixtures that were already set up **do** run their teardown, in the usual reverse order. So a failure part-way through a chain unwinds cleanly for everything that had been constructed. ## Keep the graph wide, not deep Because every dependency of a named fixture is set up before the test, a long chain means each test pays for the whole chain even when it wanted only the last link. In a suite for an internal admin console it is usually better to have several small fixtures a test can name individually — a seat, a role, a log — than one `everything` fixture that transitively drags in the rest. Depth also makes failures harder to read: the further down a chain the throw happened, the more setup already ran and had to unwind. ## Quick checklist - Name what you need; do not reorder keys hoping to change execution order. - Expect teardown to unwind in reverse, and use that to talk to dependencies after `use`. - Break a cycle by extracting a third fixture, never by duplicating setup. - Prefer several small fixtures over one deep chain.