Top 50 Playwright TypeScript Interview Questions and Answers

Playwright Test is an end-to-end test framework for reliable automation of modern web applications across Chromium, Firefox, and WebKit.

A Browser is the browser process, a BrowserContext is an isolated browser session, and a Page is a tab or popup within a context.

Playwright supports Chromium, Firefox, and WebKit through browser builds that it tests and distributes.

Install Playwright Test, install its browser binaries, add tests, and run them with the Playwright test command.

The config defines suite-wide runner settings such as test directories, timeouts, projects, reporters, retries, workers, and shared use options.

Most Playwright operations return promises, so awaiting them preserves execution order and propagates failures correctly.

A test has a title, fixtures such as page, actions that arrange and exercise behavior, and web-first assertions that verify outcomes.

A Locator is a reusable query that resolves elements when an action or assertion runs and includes automatic waiting and retry behavior.

Prefer user-facing locators such as getByRole, getByLabel, and getByText, then explicit test IDs when a stable test contract is needed.

An operation requiring one target fails when its locator matches multiple elements, exposing ambiguity instead of choosing silently.

Before acting, Playwright waits for the locator to resolve and for actionability checks such as visibility, stability, event reception, and enabled state.

Web-first assertions repeatedly evaluate a browser condition until it passes or reaches the assertion timeout.

By default, each test gets a fresh BrowserContext, providing clean cookies, storage, and pages while the worker can reuse its browser process.

Use relative paths with page.goto so Playwright resolves them against the configured baseURL.

Use UI Mode, the Playwright Inspector, headed execution, debug logs, and trace viewer according to the failure.

Use frameLocator to locate through the iframe boundary, or page.frame when direct Frame APIs are required.

Start waiting for the popup event before triggering the action, then await both and interact with the returned Page.

Register a page dialog handler before the triggering action, inspect the dialog, and accept or dismiss it.

Call setInputFiles on a file-input locator, or handle the filechooser event when the input is not directly accessible.

Begin waiting for the download event before the triggering action, then inspect or save the Download artifact.

Authenticate once in controlled setup, save the context's reusable state, and configure tests or projects to load it into fresh contexts.

Use BrowserContext cookie APIs, storageState, and page evaluation for storage that must be manipulated in the page origin.

Fixtures provide typed, lifecycle-managed dependencies such as browser, context, page, and request to tests and hooks.

Use per-test hooks for independent setup and cleanup, and all-hooks only for worker-local resources that are safe to share.

Projects are named configurations that run tests with different browsers, devices, environments, or dependencies.

Tags support filtering, while annotations attach structured context such as issue references or reasons to tests and reports.

A failed test can be rerun up to the configured retry count, and its failed worker process is discarded before execution continues.

Workers are independent operating-system processes that execute tests; the worker count limits concurrent execution.

Sharding splits the suite across separate Playwright invocations or machines, while workers provide concurrency inside each invocation.

Capture enough failure evidence to diagnose CI issues while controlling runtime, storage, and sensitive-data exposure.

Register page.route or browserContext.route before the request, then continue, fulfill, or abort matching requests.

APIRequestContext sends HTTP requests for API testing, test-data setup, authentication, and validation alongside browser tests.

Intercept the request, fetch the real response through the route, modify the required fields, and fulfill with the adjusted response.

A page object should expose meaningful user operations and stable Locators while hiding page-specific interaction details.

Extend the base test with typed fixtures that construct page objects from existing fixtures and pass them through the use callback.

Read validated environment values at runtime, keep secrets in an approved secret store, and never commit credentials or authenticated state.

Choose reporters for each audience, preserve machine-readable results and artifacts in CI, and merge shard blobs into one coherent report.

Use a reproducible runtime, start or connect to the test application deterministically, bound concurrency, retain failure evidence, and fail on real test errors.

Reproduce under representative load, inspect retry traces and logs, identify the unstable boundary, and fix state, locator, data, or synchronization causes.

Redesign around Locators, web-first assertions, context isolation, and fixtures instead of translating WebDriver calls line by line.

Playwright builds a dependency graph, sets fixtures up in dependency order, and tears them down in reverse according to test or worker scope.

Prefer a setup project when setup benefits from Playwright fixtures, reporting, traces, retries, and explicit dependency ordering.

Give each test or worker unique data, avoid shared mutable identities, and clean up through APIs or isolated environments.

HAR replay is useful for deterministic testing against recorded HTTP traffic when a dependency is costly, unstable, or unavailable.

Use separate, evidence-based test, expect, action, and navigation limits, and override them narrowly for genuinely slower operations.

Identify the application's completion signal and assert the new result state before selecting an item.

Create separate BrowserContexts with role-specific storage state and use one Page per context.

Reproduce the exact project and environment, inspect CI traces and logs, and test browser-specific assumptions before changing timeouts.

Mock that dependency in checkout-focused tests and retain a smaller separate layer that validates the real sandbox integration.

Profile the suite, remove redundant UI setup, ensure data isolation, then tune workers and distribute tests with sharding based on measured capacity.