18 Playwright Fixture Lifecycle Interview Scenarios

Fixture interviews reveal whether a candidate can assign ownership to test infrastructure. A short answer about reusable setup is not enough. Senior engineers must reason about resource lifetime, parallel mutation, dependency order, retries, and what the report will show when either setup or cleanup fails.

These scenarios use realistic account, API, page-object, and diagnostics fixtures. For each one, state the lifecycle you want, identify who owns cleanup, and explain how a failure would be investigated. That is the difference between a convenient helper and a fixture architecture that survives a large suite.

Frame the Fixture Decision

The official Playwright fixtures guide describes fixtures as isolated, composable, and demand-driven. A senior answer converts a setup requirement into a scope choice and dependency graph, then follows the resource through teardown. It should also challenge the premise when the requested sharing would make tests order-dependent.

Strong candidates resist optimizing scope before they understand mutation. They also keep the primary product assertion outside setup so the report says whether resource preparation or application behavior failed.

Ownership and Basic Lifecycle

1. Why would you replace a repeated beforeEach with a custom fixture?

I would replace it when the setup provides a named capability used across suites, especially if it has dependencies or cleanup. The fixture makes consumption explicit in the test signature and runs only when requested. A small local hook can remain clearer for one describe block. The decision is not about eliminating hooks; it is about giving a reusable resource a visible owner and a predictable lifetime.

2. How does the call to use define fixture ownership?

Code before use(resource) prepares the capability, the call yields it to the test or dependent fixture, and code after the call performs teardown. I would keep that sequence readable and avoid multiple ownership paths. If setup partially succeeds, the implementation should track what was created so cleanup can be conditional. The fixture should not call use with an invalid object just to keep the test running.

type Fixtures = { order: { id: string } }

export const test = base.extend<Fixtures>({
  order: async ({ request }, use) => {
    const response = await request.post('/api/test/orders')
    expect(response.ok()).toBeTruthy()
    const order = await response.json()

    await use(order)

    await request.delete(`/api/test/orders/${order.id}`)
  },
})

3. Why should a page object usually be test-scoped?

A page object commonly wraps the test-scoped page, so it must share that lifetime. It may also contain locators whose meaning depends on one context's cookies, navigation, and DOM. Making it worker-scoped would either create an invalid dependency or encourage state sharing across tests. Constructing the wrapper is cheap; the expensive resource question belongs to the browser, account, or backend setup instead.

Scope and Parallel Isolation

4. When is worker scope appropriate for an authenticated account?

Worker scope can fit when each worker receives its own account and tests assigned to that worker do not mutate conflicting profile or business state. I would namespace the lease by worker identity and document what may be changed. If tests edit permissions, carts, or credentials, test-scoped accounts are safer. Authentication cost alone does not justify sharing a mutable identity across unrelated cases.

5. Why can a worker fixture still be created more than once in a run?

Workers are processes, not permanent suite singletons. A worker may stop after a failure, and a retry can execute in another worker with a newly initialized fixture. Sharding and project execution also create separate worker populations. Setup must therefore be repeatable, and external resource keys must tolerate recreation. A candidate who promises exactly-once behavior from worker scope is assigning a guarantee the runner does not provide.

6. How would you allocate unique data to parallel workers?

I would derive a stable pool slot from workerInfo.parallelIndex, lease an account or namespace for that slot, and release it during worker teardown. I would not use a single process-global counter because CI shards and separate machines cannot coordinate it. The external leasing service should reject duplicate ownership and record the run identifier so abandoned leases can be diagnosed and expired safely.

type WorkerFixtures = { workerAccount: Account }

export const test = base.extend<{}, WorkerFixtures>({
  workerAccount: [async ({}, use, workerInfo) => {
    const account = await leaseAccount(workerInfo.parallelIndex)
    await use(account)
    await releaseAccount(account.id)
  }, { scope: 'worker' }],
})

Dependencies and Composition

7. How does Playwright order fixture dependencies and teardown?

Playwright sets up a dependency before the fixture that requests it. After the consumer finishes, teardown proceeds so the dependent fixture can clean up while its dependencies are still available. I would express an API client or namespace in the fixture parameter list instead of importing a hidden global. That dependency graph communicates both initialization and release order to the runner and to reviewers.

8. Why can a worker fixture not depend on a test-scoped fixture?

The worker resource lives longer than any individual test resource. Depending on page or another test-scoped value would leave the worker fixture holding something that is destroyed after one test. I would either move the consumer to test scope or introduce a worker-safe dependency, such as a standalone service client. Scope must flow from longer-lived dependencies to compatible consumers, never borrow a shorter lifetime.

9. How would you combine fixture modules owned by different teams?

I would expose a deliberate shared test export, compose independent modules with the supported merge utility, and verify fixture names do not collide. Specs should import from that stable boundary rather than choose ad hoc base tests. I would also keep domain fixtures independent where possible; a payments fixture should not silently trigger catalog setup. Composition is valuable only if requested capabilities and ownership remain visible.

Options, Overrides, and Automatic Setup

10. Why use an option fixture for a default role instead of reading process.env in every fixture?

An option fixture gives the role a type, default, and override path through project or suite configuration. Resource fixtures can depend on it without knowing where configuration originated. Repeated environment reads spread parsing and fallback behavior across the suite. I would validate environment input once at the configuration boundary, then pass the domain value as an option. Secrets remain protected inputs, not option values printed casually in reports.

11. How would you override a fixture without losing its type contract?

I would extend the established test export and provide a replacement implementation with the same declared value type. The override must preserve the behavioral contract expected by consumers, including cleanup. If its semantics differ substantially, a new fixture name is clearer. I would run representative setup, failure, and teardown cases because TypeScript can prove shape compatibility but cannot prove that lifecycle ownership stayed equivalent.

12. When is an automatic fixture justified?

An automatic fixture is justified for a cheap concern required by every test, such as collecting browser logs and attaching them only on failure. It is not a good default for login, navigation, or data seeding because tests then hide their dependencies and pay setup cost even when irrelevant. I would require a clear universal policy, bounded memory use, and a report that distinguishes diagnostics collection from the product scenario.

Failure and Teardown Analysis

13. How should a fixture fail when account creation returns an error?

It should stop during setup, close to the failed API call, and include the response status plus a safe correlation identifier. It should not call use with placeholder credentials or let the test fail later at login. If any partial account was created, cleanup should use the recorded identifier. This makes the report classify the incident as environment or setup failure rather than a misleading product assertion.

14. How do you prevent teardown failure from obscuring the original test failure?

I would make cleanup idempotent, handle expected not-found responses, and attach cleanup diagnostics through testInfo instead of throwing for every benign condition. A real cleanup failure should still be reported, but logs must preserve the original assertion and its trace. Cleanup should never catch and replace the test error. Recording both outcomes gives maintainers the evidence to fix product behavior and resource leakage independently.

15. Why is closing a shared browser from a test fixture dangerous?

The built-in browser may be owned at a broader runner scope and used by other tests. A fixture should close only the contexts, pages, clients, or external resources it created. Closing a dependency it did not create violates ownership and can generate unrelated failures in parallel work. I would review construction and teardown as a pair: the code that acquires a resource is responsible for releasing that exact resource.

Reporting, Retries, and Maintainability

16. How would boxed fixtures improve a report, and what could they hide?

Boxing can reduce noisy fixture steps so a test report emphasizes domain actions. That helps when low-level setup is stable and its internal steps add little value. It can also hide the operation needed to diagnose a setup failure. I would box only well-understood plumbing, give the fixture a meaningful title, and retain attachments or logs that reveal the failing external call when setup does break.

17. How should a fixture behave across retries?

A test-scoped fixture should create a clean resource for each attempt and avoid reusing state left by the failed attempt. A worker-scoped fixture may survive or be recreated depending on worker lifecycle, so tests cannot rely on either outcome for correctness. I would make setup repeatable, data uniquely addressed, and cleanup idempotent. A retry that passes only because it receives fresh shared state is evidence of leakage.

18. How would you review a giant fixture that returns pages, users, and API clients together?

I would map which tests use each capability and split resources by lifecycle and domain responsibility. A single object encourages unnecessary setup, hides dependencies, and makes cleanup all-or-nothing. Small fixtures can still compose through explicit parameters. I would migrate one consumer group at a time, preserving import compatibility where practical, and compare traces to ensure the new graph makes failures easier to locate rather than merely increasing file count.

Fixture Design Checklist

• Name the capability a test receives, not the setup procedure that happens internally.
• Start with test scope unless sharing is both valuable and proven safe.
• Express every lifecycle dependency in fixture parameters.
• Keep secrets out of fixture names, errors, attachments, and storage artifacts.
• Make partial setup and repeated cleanup safe.
• Leave scenario assertions in the test unless they are universal resource invariants.
• Exercise parallel execution, a forced setup failure, a test failure, and a teardown failure.

Conclusion: Make Resource Ownership Obvious

The best fixture interview answer makes lifetime and ownership boringly clear. The test requests a capability, Playwright builds only the required graph, and the code that acquires each resource releases it without erasing evidence. Optimize with worker scope, automatic fixtures, or boxing only after isolation and reporting are sound. A suite scales when every setup failure can be located and every shared resource has a defensible boundary.