Playwright Web Automation Interview Questions

A Browser is one launched browser process; a BrowserContext is an isolated session within it (its own cookies/storage, like an incognito profile); a Page is a single tab within a context. Multiple contexts can run in parallel from one browser instance without sharing state.

Each context has isolated cookies, local storage, and session state, so tests don't leak state between each other -- reusing one context risks one test's login/session affecting another test's starting conditions.

Role-based locators target how a real user and assistive technology perceive the page (button, link, heading, by accessible name), which is far more stable across styling/markup refactors than a CSS class name that might change for purely visual reasons unrelated to the element's actual function.

await page.getByRole("button", { name: "Submit" }).click();

Common mistake: Locating elements by CSS class names tied to styling, which break whenever the page's visual design is refactored even if the element's function hasn't changed.

`getByText` locates by visible text content; `getByTestId` locates by a dedicated `data-testid` attribute, independent of visible text or styling. `getByTestId` is justified when no accessible role/label/text reliably identifies the element (e.g. a purely decorative or dynamically-generated element with no stable accessible name).

No -- a locator is a lazy, re-evaluated query. It doesn't resolve to an actual DOM element until an action is performed on it, and re-resolves fresh each time, which is part of why locators handle dynamically-changing pages well.

Chain locators -- e.g. `page.getByRole("listitem").filter({ hasText: "Milk" }).getByRole("button")` -- or call `.locator()`/`getByRole()` on an existing locator to narrow the search to its descendants.

Playwright throws a strict-mode violation error rather than silently clicking the first match -- ambiguous locators must be narrowed (with `.first()`, `.nth()`, or a more specific selector) before an action can proceed.

The accessible name is the text a screen reader announces for an element -- derived from its visible text, an `aria-label`, or an associated `<label>`. `getByRole(role, { name })` matches against this computed accessible name, not just raw inner text.

Writing tests with `getByRole`/accessible names forces the underlying markup to actually expose correct roles and labels for elements to be locatable at all -- an inaccessible element (no role, no label) becomes hard to test, surfacing accessibility gaps as a natural side effect of writing tests.

It gives you a Frame object scoped to that iframe's own document, letting you locate and interact with elements inside the iframe -- locators on the main page cannot directly reach into an iframe's separate document.

Before performing an action (click, fill, etc.), Playwright automatically waits for the target element to be visible, stable, and enabled -- eliminating the need for manually-tuned fixed `sleep()` calls that older tools relied on, which were either too short (flaky) or too long (slow).

It's either wasteful (waiting longer than necessary when the app responds quickly) or still flaky (too short when the app is briefly slower than usual) -- a web-first assertion that waits for the actual expected condition is both faster on average and more reliable.

Common mistake: Using page.waitForTimeout() as a substitute for a proper web-first assertion, producing a test that's both slower than necessary and still occasionally flaky.

A web-first assertion (like `expect(locator).toBeVisible()`) automatically retries until the condition is true or a timeout is reached; a one-time `.isVisible()` check returns the current state immediately with no retrying, so it can report false negatives on elements that just haven't rendered yet.

It prevents the test from proceeding to interact with the old page's elements or asserting on stale content before the navigation actually completes, avoiding a race between the click's navigation and the next test step.

Fill each field with `.fill()` (which waits for the field to be actionable), click the submit control, then assert on the expected post-submit state -- either a success indicator or, if validation should fail, an assertion that the expected error message becomes visible.

`.fill()` sets an input's value directly and fires the relevant events, which is fast and reliable for most cases; `.type()`/`.pressSequentially()` simulates individual keystrokes, which is slower but necessary when testing behavior that specifically reacts to each keypress (like a live-search autocomplete).

Register a `page.on("dialog", handler)` listener before the action that triggers the dialog, and call `dialog.accept()` or `dialog.dismiss()` inside the handler -- Playwright otherwise auto-dismisses unhandled dialogs by default, which can silently change test behavior if not accounted for.

Use `locator.setInputFiles(path)` on the file input element (or the element that opens a native file chooser), which programmatically supplies the file without needing to interact with the OS-level file picker dialog.

Wrap the triggering action in `page.waitForEvent("download")` (or the equivalent `expect` helper), which resolves with a Download object once the browser starts the download, letting you assert on its suggested filename or save it for inspection.

A new tab/window opened by the page under test (e.g. via `target="_blank"` or `window.open()`) -- you capture it with `page.waitForEvent("popup")` around the triggering action, which returns a new Page object you can then interact with independently.

`page.route()` intercepts requests matching a pattern and lets you fulfill them with a custom response -- useful for reliably testing hard-to-reproduce states like a 500 server error or a slow/timed-out response, without needing the real backend to actually fail on demand.

await page.route("**/api/orders", (route) =>
  route.fulfill({ status: 500, body: "Server error" }),
);

`page.route()` actively intercepts and can modify/mock a matching request before it's sent; `page.waitForResponse()` passively observes and waits for a real network response matching a pattern, used to assert that a real request completed as expected without altering it.

It lets a test send real HTTP requests directly (like a lightweight API client), without driving a browser page -- useful for fast test setup/teardown (e.g. creating test data via an API call) or for testing an API's behavior directly rather than only through UI interactions.

Driving the UI to create prerequisite data (e.g. signing up a user, creating an order) is slower and more failure-prone than a direct API call, and couples every test's setup to unrelated UI flows that could themselves be flaky or change.

Perform the login once (typically in a setup project/step), then call `context.storageState({ path: "auth.json" })` to save cookies/local storage, and reuse that file via the `storageState` option in later test projects to start already authenticated.

A named test configuration (in `playwright.config.ts`) with its own browser, viewport, or `use` options -- letting the same test files run across multiple projects (e.g. chromium, firefox, webkit, or an authenticated vs. unauthenticated setup) without duplicating test code.

A single `page.route()` handler with a generic pattern applies to every matching request by default, so if different calls to the same endpoint need different mock responses, the handler must inspect the request (e.g. query params) to return the right response for each call.

Use `page.route()` to intentionally delay the mocked response (or add an artificial delay before calling `route.continue()`/`route.fulfill()`), then assert the spinner is visible during that window and disappears once the (mocked) response resolves.

Parallel tests running against a shared environment can conflict if they operate on the same hardcoded record (e.g. two tests both editing 'user123') -- generating unique data per test run avoids cross-test interference and flakiness caused by shared state.

Common mistake: Hardcoding the same test-data identifiers across tests that run in parallel, causing tests to interfere with each other's state.

`route.continue()` lets the intercepted request proceed to the real network (optionally with modified headers/method/postData), while `route.fulfill()` short-circuits it entirely and returns a custom response without the request ever reaching the real server.

A fixture provides a reusable piece of test setup/teardown (like a logged-in page, or seeded test data) that Playwright injects into any test that declares it as a parameter -- it avoids duplicated setup logic and automatically handles teardown, unlike manually copy-pasted `beforeEach` code repeated across files.

A design pattern where each page/component's locators and interactions are encapsulated in a dedicated class, so tests call semantic methods (`loginPage.login(user, pass)`) instead of repeating raw locators -- when the UI changes, only the page object needs updating, not every test that uses it.

Hardcoded data can collide with existing records, leftover data from failed previous runs, or other parallel tests -- generated unique values (like a timestamp-based email) keep each test run self-contained and independent of the environment's prior state.

A `beforeEach` hook runs before every test in a file/describe block, always doing the same setup regardless of whether a given test needs it; a fixture is only instantiated when a test actually declares it as a dependency, and can be composed/scoped more flexibly (e.g. worker-scoped vs. test-scoped).

Test files are typically committed to version control, so hardcoded secrets become part of the repository's history and visible to anyone with repo access -- credentials should come from environment variables or a secrets manager instead, kept out of the codebase.

Common mistake: Hardcoding a test account's password directly in a spec file, which then persists in git history indefinitely even if later removed.

Independent tests don't rely on side effects from a previous test having run first -- if tests depend on order (e.g. test B assumes test A already created a record), running them in isolation, in a different order, or in parallel can cause unexplained failures.

Small, focused fixtures can be mixed and matched per test (a test needing auth but not seeded data only declares the auth fixture), and are individually easier to understand, test, and reuse than one large fixture with many unrelated responsibilities baked in.

Keeping assertions in the test file (not the page object) keeps the page object reusable purely as an interaction layer, and keeps the test's actual expected behavior visible and readable directly in the test, rather than hidden inside a helper class.

A smoke test is a small, fast subset of critical-path checks (e.g. "can a user log in and see the dashboard") run frequently to catch major breakage quickly; a full regression suite covers edge cases and secondary flows more thoroughly but takes longer to run.

Leftover test data accumulates over repeated runs, can slow down or pollute a shared test environment, and may eventually collide with future test data or make debugging failures harder by mixing old and new state.

A flaky test passes and fails intermittently without any real code change, usually due to a race condition or unreliable wait -- it's worse than a consistently-failing test because it erodes trust in the whole suite, since a real failure can be dismissed as 'probably just flaky' and ignored.

A recorded, step-by-step timeline of a test run (DOM snapshots, network requests, console logs, screenshots) that you can replay visually -- letting you see exactly what the page looked like and what happened at the moment of failure, without needing to reproduce it live.

Retries can mask the underlying race condition or timing issue causing the flakiness, letting the suite stay green while the root cause remains unaddressed -- the flakiness can resurface later or under different conditions (e.g. a slower CI runner) unless actually diagnosed and fixed.

Common mistake: Treating automatic retries as a permanent fix for a flaky test instead of a temporary mitigation while the root cause is investigated.

Playwright distributes test files across multiple worker processes, each an isolated Node.js process running a subset of the suite concurrently -- by default, tests within one file run in order on one worker, while different files can run in parallel across workers.

If two parallel tests read and write the same shared record simultaneously, their operations can interleave unpredictably, causing either test to see unexpected state -- each test needs its own isolated data to be safely parallelizable.

The overall test timeout bounds how long the entire test is allowed to run before being forcibly failed; a web-first assertion's own timeout bounds how long that specific assertion will keep retrying before failing -- a slow assertion can still fail on its own timeout well before the overall test timeout is reached.

CI environments often run slower/differently-resourced machines, different network latency, different screen/viewport defaults, or headless-vs-headed rendering differences -- any of these can expose timing assumptions or environment-specific behavior that a developer's faster local machine masked.

It preserves the exact visual and diagnostic state at the moment of failure for later review, since the CI environment (unlike a developer's local machine) usually can't be re-run interactively on demand -- without it, a failure investigated after the fact has little more than a stack trace to go on.

Many real users navigate exclusively via keyboard (screen-reader users, motor-impairment users); a page can look correct visually while being completely unusable by keyboard alone if focus order is broken or an interactive element isn't keyboard-reachable -- automated checks that only look at visual rendering miss this entirely.

It means the suite stays cheap to update as the app evolves -- reusable page objects/fixtures instead of duplicated locators, resilient selectors that don't break on cosmetic changes, independent tests, and clear failure diagnostics -- rather than a suite that technically passes today but is expensive and fragile to keep passing over time.