Advanced Playwright TypeScript Interview Questions: Fixtures, Projects, Sharding and Architecture

These advanced Playwright TypeScript interview questions go beyond the basics into how Playwright Test actually works: fixtures and their scopes, projects as a browser matrix and as a setup dependency graph, authentication with storageState, debugging, parallelism and sharding in CI, API and network features, and architecture decisions. For the core question set, start with the Playwright interview questions.

Section 1 — The Test Runner & Fixtures (Deep)

How the fixture system actually works

Explain Playwright fixtures in depth. How do setup and teardown work?

A fixture is a function that builds a value, hands it to the test, and then cleans it up — the runner injects it by name via destructuring.

A fixture is defined with base.extend(). Everything before the use() call is setup; the value you pass to use() is what the test receives; everything after use() is teardown, and it runs even if the test fails. The runner reads the fixture NAMES a test destructures and only builds those — lazy instantiation — so unused fixtures cost nothing.

export const test = base.extend<{ loginPage: LoginPage }>({
  loginPage: async ({ page }, use) => {
    const loginPage = new LoginPage(page);   // 1. setup
    await loginPage.goto();
    await use(loginPage);                     // 2. hand to the test
    // 3. teardown (runs after the test, even on failure)
  },
});

This is why fixtures replace the Java base-class + factory pattern: instead of @BeforeEach/@AfterEach in an inheritance chain, each concern (a page object, an authenticated context, seeded data) is an independent, composable unit that declares its own setup and teardown and its own dependencies.

Test-scoped vs worker-scoped fixtures — when and why?

Test fixtures are rebuilt for every test (isolation); worker fixtures are built once per worker process and shared across all tests that worker runs (performance).

• Default scope is "test" — a fresh value per test, which is what you want for the page, for data that must not leak, for anything stateful.
• Worker scope ({ scope: "worker" }) is for EXPENSIVE, SAFE-TO-SHARE setup: a logged-in account, an auth token, a seeded reference dataset, a started test server.
• Trade-off: worker fixtures amortize cost across many tests but must be immutable/read-only, or tests will contaminate each other.

export const test = base.extend<{}, { account: Account }>({
  account: [async ({ browser }, use) => {
    const account = await createAccountOnce();   // once per worker
    await use(account);
    await deleteAccount(account);
  }, { scope: "worker" }],
});

What are automatic and option fixtures?

• Automatic fixture ({ auto: true }) runs for every test WITHOUT being requested — ideal for cross-cutting concerns like attaching a logger, starting tracing, or wrapping each test in setup you always want.
• Option fixture ({ option: true }) defines a configurable default that any project or test can override with test.use({...}) — this is how you parameterize behaviour (e.g. a "userRole" option) cleanly from config.

Together, auto + option fixtures let you build a framework where behaviour is declared in config and applied automatically, with zero boilerplate in the test body.

How do you override a built-in fixture, and why would you?

You redefine it in extend() or set it with test.use(). The classic case is the storageState fixture — you override it so a group of tests runs as a specific role. You can also override page/context options (locale, viewport, permissions) per file or per describe block.

test.use({ locale: 'de-DE', viewport: { width: 1280, height: 720 } });
test.describe('admin area', () => {
  test.use({ storageState: 'auth/admin.json' });   // this block runs as admin
  test('...', async ({ page }) => { /* ... */ });
});

Section 2 — Config, Projects & Authentication Architecture (Deep)

Projects as a matrix AND as a dependency graph

What are projects, and what two very different jobs do they do?

A project is a named test run with its own settings. Projects do double duty: they are your browser/device MATRIX, and they are a DEPENDENCY GRAPH for setup/teardown.

• As a matrix: one project per browser/device (Desktop Chrome, Firefox, WebKit, iPhone), each with its own use options; the same tests run across all of them.
• As a dependency graph: a project can declare dependencies: ["setup"] so a setup project runs first, and teardown: "cleanup" so a teardown project runs last.
• This is how authentication is done idiomatically — a setup project logs in and writes storageState, and the real projects depend on it and consume that state.

export default defineConfig({
  projects: [
    { name: 'setup', testMatch: /.*\.setup\.ts/ },
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'], storageState: 'auth/user.json' },
      dependencies: ['setup'],       // run setup first
    },
  ],
});

globalSetup vs a setup project — which and why?

Prefer a setup project. globalSetup is a lower-level hook that runs once with NO access to fixtures, the trace, or the reporter.

• globalSetup: a plain function(config) that runs once before everything. Good for non-browser work — starting a server, seeding a database. It cannot use fixtures or produce per-test artifacts, and failures are harder to debug.
• Setup project: a normal test file, so it has fixtures, auto-wait, assertions, tracing and reporting. It can log in through the real UI and save storageState, and other projects depend on it. This is the recommended pattern for auth.

Design authentication for an app with three roles.

Create a setup project that logs in as each role and writes one storageState file per role (admin.json, editor.json, viewer.json). Then either give each role its own project consuming its file, or use test.use({ storageState }) per describe block. For very large suites, make auth a worker-scoped fixture so each worker logs in once and reuses the session across its tests.

// auth.setup.ts
for (const role of ["admin", "editor", "viewer"]) {
  setup(`login as ${role}`, async ({ page }) => {
    await loginAs(page, role);
    await page.context().storageState({ path: `auth/${role}.json` });
  });
}

Section 3 — Assertions, Waiting & Determinism (Deep)

The two kinds of expect, and killing flakiness

Explain retrying vs non-retrying assertions.

expect(locator) auto-retries; expect(value) checks once. Confusing the two is a top cause of flaky suites.

When you assert on a Locator — expect(locator).toBeVisible() — Playwright POLLS: it re-evaluates the DOM until the condition holds or the assertion timeout (5s) expires. When you assert on a plain value — expect(count).toBe(3) — it runs once, immediately. So if you read a value into a variable and then assert on the variable, you lose the retry and reintroduce the race you were trying to avoid. Keep the locator inside the expect wherever possible.

// GOOD — retries until the badge shows 3
await expect(page.getByTestId('cart-badge')).toHaveText('3');

// RISKY — reads once, asserts once (no retry)
const text = await page.getByTestId('cart-badge').textContent();
expect(text).toBe('3');

When do you use expect.soft, expect.poll and toPass?

• expect.soft(...) — record a failure but keep going, so one test can report several problems at once (e.g. validating many fields on a page). The test still fails at the end.
• expect.poll(fn) — retry a non-locator value that changes over time: await expect.poll(() => getApiCount()).toBe(3). Use it when the thing you are checking is not a Locator (an API count, a computed total).
• expect(async () => { ...assertions... }).toPass() — retry a whole BLOCK of steps until they all pass; useful for eventually-consistent flows where several conditions must line up together.

How do you make tests deterministic instead of using sleeps?

Never use page.waitForTimeout() (a hard sleep). Rely on auto-wait for actions and web-first assertions for state. For explicit synchronization, wait on the exact event: waitForResponse for a specific API call, waitForURL for navigation, or locator.waitFor({ state }) for an element state. When triggering an event that produces a popup or download, start the wait BEFORE the click with Promise.all, so you never miss the event.

const [response] = await Promise.all([
  page.waitForResponse('**/api/cart'),
  page.getByRole('button', { name: 'Add to cart' }).click(),
]);
expect(response.ok()).toBeTruthy();

Section 4 — Parallelism, Sharding & Scale (Deep)

How the runner parallelizes, and how to scale it

Explain Playwright’s parallelism model end to end.

The runner spawns worker processes; it distributes test FILES across them; within a file tests run serially by default; each worker owns its own browser.

• Workers are OS processes (default = half your CPU cores). Each worker launches its own browser and gives every test a fresh, isolated context+page — which is why there is no ThreadLocal to manage as in Java.
• Files are the unit of distribution: different files run on different workers concurrently.
• Within one file, tests run in order by default (they may share worker-scoped state). Opt a file into concurrent tests with test.describe.configure({ mode: "parallel" }); fullyParallel: true in config does this everywhere.
• If a test fails and retries are on, it runs in a clean worker — so a poisoned worker never cascades failures.

How do you shard a large suite across CI machines?

Sharding splits the tests across N machines deterministically, and you merge the per-shard reports into one at the end.

• Run --shard=1/3, --shard=2/3, --shard=3/3 on three CI runners in parallel. Playwright splits at the test level so each shard does roughly a third of the work.
• Each shard produces a "blob" report (a portable, mergeable artifact). Configure the blob reporter for CI.
• After all shards finish, download the blobs and run npx playwright merge-reports to produce a single unified HTML report.
• Result: a 40-minute suite finishes in ~13 minutes on three runners, with one report to read.

# CI: three parallel jobs
npx playwright test --shard=1/3
npx playwright test --shard=2/3
npx playwright test --shard=3/3
# afterwards, in a merge job:
npx playwright merge-reports --reporter html ./all-blob-reports

A test is flaky only in CI. Walk through your investigation.

• Open the trace from the failed CI run (trace: "on-first-retry" captures it cheaply) and time-travel to the exact failing step.
• Check for a real race: an assertion reading data that arrives via a later network call → switch to a web-first assertion or waitForResponse.
• Check isolation: is state leaking from a worker-scoped fixture or shared data? Make it read-only or test-scoped.
• Check CI-only differences: viewport, timezone/locale, animations, a slower machine — pin them and disable animations; raise a targeted timeout if genuinely needed.
• Only after ruling out real bugs, allow retries for a genuinely non-deterministic external dependency — retries mask flakiness, they do not fix it.

Section 5 — API, Network & Advanced (Deep)

Combining API and UI, and controlling the network

How do you design an API + UI hybrid test, and why?

Do slow, repetitive setup through the API and reserve the UI for the behaviour you are actually verifying.

The request fixture is a full HTTP client. Use it to create the preconditions fast — seed a user, place an order, set a feature flag — then switch to the page to assert the user-visible result. This keeps tests fast and focused: you are not clicking through five forms just to reach the screen under test. The two share nothing by default, but you can carry cookies/session between them when needed.

test('order shows in history', async ({ request, page }) => {
  const res = await request.post('/api/orders', { data: order });
  expect(res.ok()).toBeTruthy();
  await page.goto('/orders');
  await expect(page.getByText(order.id)).toBeVisible();
});

Explain the network interception options and a real use for each.

• route.fulfill(...) — return a mock response. Use it to render a screen with fixed data, or to force an error state (status 500) that is hard to reproduce against a live backend.
• route.abort() — block a request. Use it to drop images/analytics for speed, or to simulate an offline/failed resource.
• route.fetch() then fulfill(...) — fetch the real response and tweak one field (e.g. flip a role to admin) to test a variant without backend changes.
• routeFromHAR(...) — replay a recorded session so the whole test runs offline and deterministically.

Section 6 — Architecture & Migration Scenarios (Deep)

Framework design & moving from Selenium/Java

Design a scalable Playwright + TypeScript framework. Walk me through the layers.

• Config layer: playwright.config.ts with projects (browsers + setup/teardown), env-driven use options (baseURL, workers, retries via process.env), and reporters (html + blob for sharding).
• Fixtures layer: custom fixtures inject page objects, per-role auth (storageState), and seeded data — this is the dependency-injection backbone.
• Pages/components: POM with typed Locator fields; component objects for shared widgets; actions return page objects for fluent flows.
• API layer: request-based service helpers with typed bodies for setup/verification.
• Utils: data builders, custom expect matchers, a11y/visual helpers.
• Tests/specs: thin, readable, locator-free; tagged for smoke/regression.
• CI: GitHub Actions matrix + sharding, official Docker image, artifacts on failure, merged report, quality gate.

The interview signal is that behaviour lives in config + fixtures, tests stay thin, and everything is typed — so the suite scales to thousands of tests without turning into copy-paste.

How would you migrate a Java/Selenium suite to Playwright + TypeScript?

Migrate incrementally, feature by feature, starting with the flakiest and highest-value flows — never a risky big-bang rewrite.

• Run both suites in parallel during the transition so coverage never drops.
• Rebuild page objects with user-facing locators (getByRole/getByTestId) and delete explicit waits — auto-wait replaces them.
• Adopt the runner idioms: fixtures instead of base classes, projects instead of testng.xml, storageState instead of per-test login.
• Reuse what is language-agnostic: test data, environments, CI concepts, and the domain knowledge in your existing tests.
• Measure the win: track flakiness rate and suite runtime before/after to justify the effort to stakeholders.

When is Java the right choice over TypeScript for Playwright?

When the team and stack are JVM-centric — a Selenium/Java shop, backend services in Java, engineers who own the tests writing Java daily. The Playwright capabilities are the same; you trade the TS runner’s config/fixtures/UI-Mode for JUnit/TestNG familiarity and easier integration with existing Java tooling. The honest answer names it as a team/ecosystem decision, not a capability gap.

Question Bank

Section A — Fundamentals & the Test Runner

Section B — Locators & Interactions

What locators does Playwright provide (TS)?

page.getByRole('button', { name: 'Save' })
page.getByLabel('Email')   page.getByPlaceholder('Search')
page.getByText('Products')  page.getByTestId('submit')
page.locator('#id')  page.locator('//a')  // CSS / XPath

How do you handle dialogs, frames, tabs and downloads (TS)?

page.on('dialog', d => d.accept());        // register before trigger
await page.frameLocator('#f').getByLabel('Card').fill('4111');
const [popup] = await Promise.all([
  page.waitForEvent('popup'), page.getByText('Open').click() ]);
const [download] = await Promise.all([
  page.waitForEvent('download'), page.getByText('Export').click() ]);
await download.saveAs(await download.suggestedFilename());

Section C — Assertions, Waiting & Debugging

List the common web-first assertions (TS).

await expect(loc).toBeVisible()/toBeHidden()/toBeEnabled()/toBeChecked();
await expect(loc).toHaveText(t)/toContainText(t)/toHaveValue(v);
await expect(loc).toHaveAttribute(n,v)/toHaveClass(c)/toHaveCount(n);
await expect(page).toHaveTitle(t)/toHaveURL(/regex/);
await expect(response).toBeOK();

How do you debug a failing TypeScript test?

• UI Mode: npx playwright test --ui — time-travel every step with DOM snapshots.
• --debug or PWDEBUG=1 opens the Inspector; add await page.pause().
• Trace Viewer: set trace: "on-first-retry" then npx playwright show-trace.
• HTML report: npx playwright show-report. Codegen to compare locators.

Section D — Fixtures, POM & Data-Driven

How do you write a Page Object in TypeScript?

import { Page, Locator } from '@playwright/test';
export class LoginPage {
  readonly page: Page;
  readonly loginButton: Locator;
  constructor(page: Page) {
    this.page = page;
    this.loginButton = page.getByRole('button', { name: 'Login' });
  }
  async login(u: string, p: string) { /* fill + click */ }
}

What are custom fixtures and why use them?

Custom fixtures inject ready-made objects (page objects, logged-in pages, test data) into tests — the idiomatic TS alternative to a Java base class + factory.

import { test as base } from '@playwright/test';
import { LoginPage } from '../pages/login.page';
export const test = base.extend<{ loginPage: LoginPage }>({
  loginPage: async ({ page }, use) => { await use(new LoginPage(page)); },
});
export { expect } from '@playwright/test';

How do you reuse authentication across tests?

Log in once in a setup project, save storageState to a file, and load it via config so every test starts authenticated.

// auth.setup.ts
setup('login', async ({ page }) => {
  await page.goto('/'); /* ...login... */
  await page.context().storageState({ path: 'auth/user.json' });
});
// playwright.config.ts
// { name: 'setup', testMatch: /auth\.setup\.ts/ },
// { name: 'chromium', dependencies: ['setup'], use: { storageState: 'auth/user.json' } }

Section E — API, Network & Advanced

How do you test an API (TS)?

test('create user', async ({ request }) => {
  const res = await request.post('/api/users', { data: { name: 'naveed' } });
  expect(res.status()).toBe(201);
  expect(res.ok()).toBeTruthy();
  const body = await res.json();
  expect(body.name).toBe('naveed');
});

Section F — Config, Parallel, Sharding & CI

How does parallelism work in the TS runner?

• Files run in parallel across worker processes (fullyParallel + workers).
• Tests within a file run serially unless test.describe.configure({ mode: "parallel" }).
• Each worker gets its own browser + isolated context automatically — no ThreadLocal.

Section G — Scenarios & TypeScript Coding

Write: verify a product list is sorted A-Z.

const names = await page.locator('.inventory_item_name').allTextContents();
expect(names).toEqual([...names].sort());

Write: add all products and assert the cart badge.

const add = page.getByRole('button', { name: 'Add to cart' });
const n = await add.count();
for (let i = 0; i < n; i++) await add.first().click();  // each click turns that button into "Remove"
await expect(page.getByTestId('shopping-cart-badge')).toHaveText(String(n));

Write: mock an empty list and assert the empty state.

await page.route('**/api/products', r =>
  r.fulfill({ status: 200, contentType: 'application/json', body: '[]' }));
await page.goto('/products');
await expect(page.getByText('No products found')).toBeVisible();

Rapid-Fire Round (One-Liners)

• Runner package? @playwright/test. Config file? playwright.config.ts.
• Fresh page per test? the page fixture.
• Custom fixture? base.extend(). Worker fixture? { scope: "worker" }.
• Run all? npx playwright test. UI mode? --ui. Debug? --debug.
• Shard? --shard=1/3. Workers? --workers=N. Serial? workers:1.
• By title? -g "text". One project? --project=chromium.
• Visual baseline? await expect(page).toHaveScreenshot().
• Soft assert? expect.soft(). Poll? expect.poll(). Retry block? toPass().
• Negate? expect(loc).not... Timeout? { timeout: ms }.
• Reuse login? storageState + setup project dependency.
• API? request fixture. Assert? expect(res).toBeOK().
• Mock? page.route(...).fulfill(). Block? route.abort().
• Run JS? page.evaluate(). Before load? addInitScript().
• Dialog? page.on("dialog", d => d.accept()) before trigger.
• Popup/download? Promise.all([waitForEvent, action]).
• Trace? use.trace:"on-first-retry"; show-trace to open.
• Codegen? npx playwright codegen. Report? show-report.
• Cross-browser? projects with devices[...]. CI image? mcr.microsoft.com/playwright.
• Merge shard reports? blob reporter + merge-reports.
• Component test? @playwright/experimental-ct-*.

120+ TypeScript questions — runner, fixtures & all. ⚡

FAQs

What are fixtures in Playwright Test?

Reusable setup and teardown that tests receive as parameters (page, context, request and your own). Fixtures can be test- or worker-scoped and replace most beforeEach/afterEach hooks.

What is sharding in Playwright?

Splitting a test suite across several machines with --shard=1/4 and similar, so each CI job runs a portion; reports from all shards can be merged afterwards.

How do you share login between tests in Playwright Test?

Use a setup project that logs in and saves storageState to a file, and make the other projects depend on it and load that state.