Scenario-Based Playwright Testing Interview Questions

Log in once in global setup, save storageState to a JSON file and set use.storageState in the config so every test starts logged in.

Run in parallel with sharding, reuse authentication state, set up data through APIs, avoid unnecessary waits, run smoke on every commit and the full suite nightly.

Turn on trace: 'on-first-retry', open the trace viewer, check network and timing, replace hard waits with web-first assertions, isolate test data and check for sharding conflicts.

Rely on auto-waiting plus a web-first assertion on the final state, disable animations in config for tests and avoid fixed timeouts.

Fetch tokens in a fixture with expiry tracking and refresh it when it is about to expire, keeping tests unaware of the details.

TypeScript + POM + custom fixtures, environment configs, API helpers for test data, tags like @smoke, sharding across CI machines, retries with traces, HTML/Allure reports, lint and review rules.

Use page.route to intercept the call and fulfil it with fixed JSON so tests do not depend on external systems.

Cover happy path, validation errors, auth and permissions, boundary values, idempotency, schema, performance and data cleanup.

The action runs without waiting, so the next step may run first — causing flaky failures or 'Target closed' errors. The @typescript-eslint/no-floating-promises rule catches it.

Send invalid payloads or missing auth and assert 400, 401 or 404 codes and the error message bodies.

Add retries with backoff for the API step, set a suitable timeout, and use mocks for non-critical dependencies.

First scope the locator to the item you mean, for example the row that contains the user's name: page.getByRole('row', { name: 'Ravi Kumar' }).getByRole('button', { name: 'Delete' }). Do not reach for first() or nth() as a quick fix, because the order can change and the test may delete the wrong record. Scoping by meaningful context is stable and readable.

This is a hydration problem: the button is visible and enabled but not yet interactive. Wait for a signal that the app is ready, such as a loaded data request or a visible element that only appears after hydration, then click. A better fix is to report it to developers, because real users hit the same issue. Avoid fixed waitForTimeout calls.

Set a written priority order: role with name, then label, placeholder or text, then test id, and CSS or XPath only as a last resort. Agree with developers to add data-testid on complex widgets. Keep locators inside page objects so a change is fixed in one place. Add a lint rule or review check against long CSS chains and nth-child selectors.

Replace class-based selectors with role, label and text locators, and agree on data-testid for widgets without good semantics. Move all locators into page objects so future changes touch one file. Add a code review rule and a lint check that flags raw CSS selectors. Share a short locator guide with developers so they know which attributes tests depend on.

Assert immediately after the action that triggers it, using a web-first assertion like toBeVisible and toHaveText, which start checking at once. Do not add sleeps before the check. If the toast is still missed, control time with page.clock so it does not auto-hide, or verify the result through the data it confirms, such as the saved record.

Fix the locale for the test with the locale and timezoneId options so the format is predictable. Build the expected string with Intl.NumberFormat using the same locale, rather than hard-coding it. If you test several locales, run them as projects or parameterised tests. For business logic, also assert the raw number through the API response.

With fullyParallel, the file's tests run in different workers, so each worker creates its own user, or tests in one worker share one user and change its state. Shared mutable data causes random failures. Give each test its own data through a test-scoped fixture, or create a unique user per worker with workerInfo.workerIndex in the name.

Measure first with the report timings. Then create data through the API instead of the UI, move read-only shared data into a worker-scoped fixture, and seed common reference data once in a setup project. Keep per-test data only for things a test changes. Cache login with storageState. This usually cuts setup time sharply without losing isolation.

Create the data inside a fixture and delete it after await use(). Fixture teardown runs even when the test fails or times out, so cleanup is reliable. Avoid cleanup steps at the end of the test body, because they never run after a failed assertion. As a safety net, tag test data with a prefix and run a nightly cleanup job.

Create two browser contexts in the same test, each with its own storageState file, for example admin.json and user.json made by a setup project. Wrap them in fixtures like adminPage and userPage so tests stay short. The admin approves an order in one context and the customer sees the update in the other, with fully separate cookies.

Worker fixtures live across many tests, so any test that changes their data affects the next ones. Keep worker fixtures read-only, such as a connection or a reference catalogue. Move anything a test modifies into a test-scoped fixture that creates fresh data. If sharing is needed for speed, reset the relevant state in the test fixture before use.

Check that the route is registered before the request is sent, usually before goto. Compare the pattern with the real URL in the trace network tab, including query strings and host. Make sure a service worker is not handling the request, and set serviceWorkers: 'block' if it is. Also check that another handler is not matching first or the route was not removed.

Mock the endpoint with route.fulfill({ status: 500, json: { message: 'Server error' } }), then open the page. Assert the user sees a friendly error message and a retry button, and that no broken half-rendered table appears. Then make the retry return 200 and check the data loads. This covers a path that is hard to trigger on a real server.

Generate mock data from the API schema or real recorded responses instead of hand-writing it. Validate mocks against the OpenAPI schema in a unit test. Add contract tests on the backend side and re-record HAR files on a schedule. Keep a few unmocked end-to-end tests that run after each deploy. Treat mock files as code with owners and reviews.

Block it in tests with context.route on its domain and route.abort, or fulfill it with an empty script. Analytics is not what you are testing, and blocking it removes delays and random network errors. If tracking events matter, write a few separate tests that capture the requests with waitForRequest and assert their parameters.

Mock the config endpoint in a fixture option so each test chooses the flag value, for example featureFlags: { newCheckout: true }. Run the flow with the flag on and off and assert the different UI. Mocking avoids changing shared environment settings that would affect other testers. Also keep one test against the real config to catch wiring mistakes.

Mock the endpoint with a counter: return Pending for the first two calls and Done after that. Then assert the UI shows Pending and later Done using web-first assertions with a suitable timeout. You can also use page.clock to speed up the polling interval instead of waiting real seconds. This makes a slow real-world process quick and deterministic.

Open the CI trace and go to the failed click. Check the action log, which shows what Playwright waited for, such as the element not being visible or another element intercepting pointer events. Compare before and after snapshots and the network tab for slow or failed calls. Common causes are a slower environment, a cookie banner or different screen size.

Collect data first: flaky results from the reports across a few weeks, grouped by test, browser and error message. Run the worst offenders with --repeat-each and traces on. Fix common causes such as missing awaits, shared data, fixed sleeps and order-dependent tests. Quarantine tests you cannot fix quickly with a tag and a ticket, and track the rate weekly.

The call log will say another element intercepts pointer events. Find what the overlay is, such as a loading mask, cookie banner or chat widget. Wait for it to disappear with expect(overlay).toBeHidden(), or close it in a fixture. Do not use force: true, because it hides a real issue: a user would also be blocked by that overlay.

Run it alone with --project=webkit --headed and record a trace. Compare it with the Chromium trace to see where behaviour differs, such as date input format, scrolling, font rendering or a missing browser API. Check the app's support matrix. If it is a real product bug, raise it, and skip the test for WebKit with a linked ticket until it is fixed.

This usually means tests share something: the same user account, the same records or a global server setting. Run the failing file with --workers=8 and --repeat-each to reproduce it. Look at which tests run at the same time in the report. Fix it by giving each test unique data, using workerIndex in names, or isolating shared settings per worker.

401 Unauthorized means the caller is not authenticated, such as a missing or expired token. 403 Forbidden means the caller is known but lacks permission. Test 401 by calling without a token or with an invalid one. Test 403 by calling an admin endpoint with a normal user's token. Assert the status and that no data leaks in the body.

Never trust status alone. Assert the body structure, for example that error is absent and data has the expected fields, ideally with a schema check. Report the issue, because returning 200 for errors breaks clients and monitoring. Add a helper that validates both status and body shape so every test checks it consistently.

Make each test own its data. Create the record inside the test or a fixture with a unique name, such as one using a timestamp or the worker index, and delete it in teardown. Avoid shared seed records for anything that gets modified. Shared read-only reference data is fine. This also lets tests run fully in parallel.

Start the job and assert the 202 status and the returned job id. Then poll the status endpoint with expect.poll, with sensible intervals and a timeout, until it reports completed. Finally fetch the result and validate it. Also test the failure path, for example invalid input leading to a failed status with a clear error message.

Do not depend on records that happen to exist in a shared environment. Each test or fixture creates what it needs through the API and cleans up after. Read environment-specific values such as base URL and credentials from config. For reference data that must exist, seed it in a setup project and verify it before tests run.

Cover empty string, missing field, null, wrong type such as a number, no at sign, no domain, spaces, very long strings and a duplicate existing email. For each, assert a 400 or 422 status, a clear error message naming the field, and that nothing was created. Also check that a valid email with uppercase letters is accepted.

If the API supports an idempotency key header, send the same POST twice with the same key and assert one order exists and both responses return the same id. Send it with different keys and expect two orders. Also try concurrent requests with Promise.all to check race conditions. Without a key, document the risk to the team.

Count the items, then scroll the last item into view with lastItem.scrollIntoViewIfNeeded() or page.mouse.wheel. Assert with expect(items).toHaveCount greater than before, for example using expect.poll on items.count(). Repeat until an end-of-list message appears. Also check no duplicates appear and that a loading indicator shows while fetching.

For most tests, avoid the pop-up: get a session through a test login API or a test identity provider and save it with storageState. Keep one test for the real flow, using const popup = page.waitForEvent('popup') before clicking, then fill the provider's form inside popup. Third-party pages can change and add captchas, so limit how often you depend on them.

forEach does not wait for async callbacks, so it starts each callback and returns at once. The test may finish before the assertions run, or their errors are lost. Use for...of with await to run steps in order, or Promise.all with map when the steps can safely run in parallel. A lint rule can flag this pattern.

The browsers are not installed on the CI machine. Add a step that runs npx playwright install --with-deps after npm ci, which downloads the browsers and the OS libraries they need. Or run inside the official Playwright Docker image that matches your Playwright version. Cache browsers to speed this step up.

Write a short contribution guide with examples. Add ESLint with the Playwright plugin and the no-floating-promises rule, plus Prettier, enforced in CI. Require reviews from framework owners for shared fixtures and page objects. Provide generators or templates for new page objects, and run regular sessions to review flaky tests together.

Use retries in CI so one-off failures do not block merges, but treat any test marked flaky in the report as a defect. Track flaky tests on a dashboard, quarantine repeat offenders with a tag and an owner, and set a deadline to fix or delete them. Never retry without investigating, or real intermittent bugs will be missed.

Playwright already marks tests that passed on retry as flaky in the HTML and JSON reports. Read the JSON report in a small script after each run, post flaky test names to the team channel, and fail the build if the flaky count crosses a threshold. Over time you can track trends per test and per area.

Read the release notes for breaking changes and deprecations. Upgrade on a branch, update the browsers and the Docker image to the same version, and run the full suite on all projects several times. Compare visual snapshots, which often change after browser updates. Upgrade regularly in small steps rather than skipping many versions.

Font rendering, anti-aliasing and installed fonts differ between Windows, macOS and Linux, so the same page produces slightly different pixels. The fix is to generate and compare baselines in one fixed environment, usually the official Playwright Docker image used in CI. Developers update baselines by running that container locally or through a CI job, not from their own machines. Loosening thresholds should be the last resort.

The default file name includes the platform, so a developer who updated baselines on Windows created a second set. Set snapshotPathTemplate in the config without the {platform} token, for example '{testDir}/__screenshots__/{testFilePath}/{arg}-{projectName}{ext}', delete the stray files and only update baselines through the Docker command or a CI job. Document the rule so it does not happen again.

First confirm the change is intended and check a sample of diffs to make sure nothing else moved. Then regenerate baselines in the CI Docker environment in a separate commit, so reviewers can see only image changes. Longer term, reduce the count: most of those tests should not snapshot full pages. Keep a few page-level shots and move detail checks to component-level screenshots of key states.

Record the current violations as a known baseline, for example by snapshotting violation ids and targets, and fail only on new ones. Fix the worst issues first, such as missing labels and contrast on key flows, and shrink the baseline every sprint. Make new pages and components meet zero violations from day one. Report the trend to the team so the debt is visible rather than silently ignored.

Open the dialog with a button and assert the dialog role is visible and focus moved inside it. Press Tab more times than there are controls and check with toBeFocused that focus never leaves the dialog. Press Escape, assert the dialog is hidden, and check that the opening button is focused again. Running the same test with Shift+Tab covers backward navigation as well.

Open the diff image in the HTML report to confirm it is just edge smoothing and not a real change. If baselines were made on a different machine, regenerate them in the CI image. If the noise is genuine and repeatable, allow a small maxDiffPixels for that assertion or project. Avoid large ratios, because they also let real layout shifts through.

toHaveScreenshot hides the text caret by default with caret: 'hide', so check that nobody set it to 'initial' and that you are not using page.screenshot with toMatchSnapshot, which lacks some of these defaults. Also blur the input or click elsewhere before the capture if focus styles change. Using the dedicated assertion gives you stable captures and retries.

Scroll the content into view or remove loading=lazy for the test, then wait until every image has loaded, for example with expect.poll checking that all img elements report complete and a natural width above zero. Serving images from mocked routes removes network timing too. Only after that call toHaveScreenshot, which then waits for two identical frames.

The request fixture returns the full body only after the stream ends, so for a short finite stream you can read text() and parse each data line. For long-lived streams, test in the browser: open the page that uses EventSource, or open it inside page.evaluate, collect events into an array and assert with expect.poll. Mock the source with a route when you need precise timing.

The test probably checks only that the wanted options are selected, for example with a loop of toBeChecked or a contains check. Replace it with await expect(select).toHaveValues(['red', 'green']), which passes only when exactly those values are selected, and it retries until the timeout. For custom multi-select widgets, assert the full list of selected chips with toHaveText on the chip locator.

Use a web-first negative assertion such as await expect(banner).toBeHidden() or not.toBeVisible(); they pass as soon as the element is absent, so they do not wait the full timeout. The real problem is timing: assert after a positive signal, such as the success message appearing, otherwise the banner may simply not have rendered yet and the check passes too early.

Create a small test story component in a separate file that builds the class instance inside the browser and renders the real component with it. The test then mounts the story with simple props, such as an id or a scenario name. This keeps the data creation on the browser side of the boundary and also documents test scenarios as reusable stories.

The app uses a bundler alias that the component test bundle does not know. Add the same alias in ctViteConfig under resolve.alias, or reuse the project's Vite config by importing it. Also make sure tsconfig paths match, so editors and type checks agree. After that, clear the cache folder that the component bundler writes under playwright/.cache so the bundle rebuilds.

Global CSS, CSS variables and fonts are normally loaded by the app's entry file, which component tests do not use. Import them in playwright/index.tsx so they are part of the test bundle. If the styling comes from a provider, such as a theme or CSS-in-JS setup, wrap the app in beforeMount. Without this, visibility and layout checks may give misleading results.

Agree to move detailed UI checks down to component tests, because they are faster and more precise. But keep a thin layer of end-to-end tests for critical journeys like signup, checkout and payment, since component tests use mocked data and cannot catch broken APIs, routing or deployment issues. Decide per risk, measure runtime savings, and track escaped defects after the change.

Give them separate configs, such as playwright-ct.config.ts with its own testDir for component specs and playwright.config.ts for end-to-end tests, because component tests also need the bundler options and framework test import. In CI, run component tests on every commit as a fast job and end-to-end tests later or in parallel. Shared settings like reporters can live in a common module both configs import.

Look for state that leaks between mounts: global stores or singletons created at module level in index.tsx, timers or listeners not cleaned up on unmount, and shared mock data mutated by one test. Make the providers create fresh state in beforeMount each time and reset mocks per test. Running with --repeat-each and a single worker often reproduces the leak quickly.

Mount the dropdown, focus the trigger and press Enter or ArrowDown to open it. Assert the listbox is visible and the first option has aria-selected or focus. Press ArrowDown again and check the active option moves, then press Enter and assert the trigger shows the chosen value and the list is closed. Finally press Escape on an open list to confirm it closes without changing the value.

Register a new page.route for /api/cart inside that test. Handlers run in reverse order of registration, so the newer one runs first. Fulfil the cart request with the special data, and for anything else call route.fallback() so the request moves on to the fixture's general handler. This keeps the shared mock untouched and makes the override local and easy to read.

Browser permission prompts are not part of the page, so you cannot click them. Instead grant the permission up front with the permissions option in the config or context, for example permissions: ['notifications'], or call context.grantPermissions. To test the denied path, create a context without the permission and assert that the app shows its fallback message.

Call both versions, for example /v1/orders/42 and /v2/orders/42, with the same test data. Map the fields that should match, since names may differ, and compare them with toEqual. Also assert that fields removed in v2 are really absent and new ones have correct types. Running this during a migration catches breaking changes before clients switch.

The best fix is to remove the shared resource, for example by giving each test its own tenant or user whose settings it can change. If that is impossible, put those tests in one file with test.describe.configure({ mode: 'serial' }), or in a separate project that runs with one worker after the main project. Document why, so the exception does not quietly spread.

Check whether fullyParallel is off, because file-level sharding puts big files together. Turn it on if tests are independent, or split the largest files. Use reportSlowTests and the merged report's durations to find heavy files, and move slow setup into API calls or shared storage state. Also check that one shard is not getting all the tests of a slow project such as WebKit.

Eight browsers compete for two cores and limited memory, so pages render slowly, actions hit timeouts and the app under test may also be overloaded. More workers than cores rarely helps. Set workers to match the runner, such as 2, and scale out with shards on more machines instead. Watch CPU and memory metrics in CI to confirm.

Generate unique data per test, for example by adding testInfo.testId, the parallel index or a random suffix to the email, or by using a data builder that creates a fresh user through the API. Avoid hard-coded shared records in test files. Clean up created users in a fixture teardown so the database does not fill up over time.

Write a custom reporter or parse the JSON report after each CI run, and store per test: id, status, retry count, duration, branch and commit. A test that passed after a retry counts as flaky. Aggregate over the last few hundred runs to rank tests by flake rate and duration, and show trends. Use it to assign owners and quarantine tests above an agreed threshold.

--last-failed works only on the machine that kept the .last-run.json file, so it does not help across shards. Instead collect the failed tests from the merged JSON report or the blob reports, then run them in a follow-up job by file and line or with --grep on their titles. Many teams simply rely on retries and treat any test needing a rerun as flaky.

Make baseURL come from an environment variable, such as process.env.BASE_URL, with a default for local runs. In the pipeline, wait for the preview deployment to be ready, read its URL from the deployment step and pass it to the test job. Add a quick health check request first, so a failed deployment is reported clearly instead of as hundreds of test failures.

Most often an action was not awaited, so the test finished and Playwright closed the page while the action was still running. Other causes are a test timeout closing the page, the code closing the page or context itself, or the browser crashing. Check the stack for the missing await, look at whether a timeout happened first, and turn on the lint rule for floating promises.

Register a route with a counter: on the first call use route.fulfill with status 503, and on later calls fulfil with a success body. Perform the action, then assert the UI shows the final data and the counter equals 2. You can also check that no error message flashed. This proves the retry logic works without waiting for a real outage.

First confirm the contract: should unknown fields be rejected with 400 or silently ignored? Then send a valid body with an extra field and assert that behaviour. If they are ignored, fetch the record and check the extra field was not stored. Also try sending a field that should be read-only, such as role or id, to catch mass assignment bugs.