Playwright interview questions and answers

Playwright is Microsoft's end-to-end testing framework for Chromium, Firefox and WebKit from one API, in TypeScript/JavaScript, Python, Java and .NET. It talks to browsers over their debugging protocols rather than WebDriver, auto-waits for elements to be actionable, isolates each test in a fresh browser context, and ships a test runner with parallelism, retries, tracing, screenshots and video.

Before an action such as click, Playwright waits until the element is attached, visible, stable (not animating), enabled and able to receive events. Web-first assertions such as expect(locator).toBeVisible() retry until they pass or time out. This removes most manual sleeps and the flakiness they cause.

User-facing ones: getByRole with an accessible name, getByLabel, getByPlaceholder, getByText, then getByTestId for elements with no good accessible handle. They match how users and assistive technology find elements, so tests survive markup and CSS changes. Avoid long CSS or XPath chains.

Group tests by feature, share setup through fixtures rather than helpers in beforeEach, keep test data independent per test, use projects for browsers and setup steps, store auth state once, tag tests (@smoke) for subsets, and run them in parallel with sharding in CI.

Assertions such as await expect(locator).toHaveText('Saved') that retry until the condition passes or times out. They wait for the app to reach the expected state, unlike checking a value once, which is the main way to avoid flaky timing problems.

Seed data through API calls or database scripts in fixtures, mock specific responses with page.route, or use HAR recordings. Each test should create or isolate its own data so tests can run in parallel without interfering.

Fixtures provide each test with what it needs, such as page, context, browser or request, and you can define your own with test.extend (a logged-in page, a seeded database, a page object). They set up on demand, tear down automatically, and can be scoped per test or per worker.

Log in once in a setup project, save the cookies and local storage with context.storageState({ path }), and configure other projects to load that state with use: { storageState }. Tests start already signed in. For several roles, save a state file per role.

Turn on traces (trace: 'on-first-retry') and open them with npx playwright show-trace to see each action, DOM snapshots, console logs and network calls. Locally use --debug, --ui mode or page.pause(). Screenshots and videos on failure help too.

Use page.route(url, handler) to fulfil requests with fixture data, modify them, or abort them. page.waitForResponse waits for a specific call. HAR files can record and replay real traffic. The request fixture calls APIs directly for setup or API tests.

Use role-based locators and web-first assertions, never fixed timeouts, keep tests independent with fresh contexts, control test data, mock unstable third parties, wait for the specific network response or UI state you depend on, and investigate retries with traces instead of hiding them.

Use page.frameLocator('iframe#pay') to work inside an iframe. For a new tab, wait for it with const popup = page.waitForEvent('popup') (or context.waitForEvent('page')) before the click, then work with the new page object.

Upload with locator.setInputFiles(path). For downloads, start waiting with page.waitForEvent('download') before clicking, then read download.path() or saveAs() and assert on the file.

Install browsers with npx playwright install --with-deps, run tests headless with retries and trace on first retry, shard across machines, cache dependencies, and upload the HTML report and traces as artifacts. The official Docker image includes all browser dependencies.

Use role-based locators (which already exercise the accessibility tree), add automated scans with @axe-core/playwright, and use toMatchAriaSnapshot to assert the accessible structure of a component.

It starts your app (for example npm run dev) before tests and waits for a URL to respond, then shuts it down afterwards. reuseExistingServer lets local runs use an already running server.

Define projects with device descriptors such as devices['iPhone 15'], which set viewport, user agent, touch and device scale factor, or set viewport per test. This emulates mobile browsers; real devices still need a device cloud.

A class per page or component that wraps locators and actions (loginPage.signIn(user)), so tests read like scenarios and a UI change is fixed in one place. With Playwright it is often combined with fixtures that create page objects for each test.

Test files run in parallel across worker processes; tests within a file run in order unless fullyParallel or test.describe.configure({ mode: 'parallel' }) is set. Each worker has its own browser, and each test its own context. In CI, --shard=1/4 splits the suite across machines.

Named configurations that run the same tests with different settings: browsers (chromium, firefox, webkit), devices such as devices['iPhone 15'], base URLs, or a setup project other projects depend on. One run can cover the whole matrix.

await expect(page).toHaveScreenshot() compares with a stored baseline and fails on differences beyond a threshold. Keep fonts, viewport and data stable, mask dynamic areas, and update baselines deliberately with --update-snapshots, ideally generated on the same OS as CI.

Use the Clock API (page.clock.install, setFixedTime, fastForward) to control Date and timers in the page, so tests for countdowns or expiring sessions are fast and deterministic.

expect.soft(...) records a failure but lets the test continue, so you see several problems in one run. The test still fails at the end.

Create one storage state per role in setup projects, then use test.use({ storageState: 'admin.json' }) per file or describe block, or create browser contexts with different states in one test.

Playwright's experimental component testing mounts React, Vue or Svelte components in a real browser with mount(). Many teams instead use Vitest browser mode or Storybook tests for components and Playwright for full flows.

It groups actions under a named step in reports and traces, making long tests easier to read and failures easier to locate.

npx playwright codegen <url> opens a browser and writes test code as you click and type, choosing resilient locators. It is a fast way to start a test or find a locator; the generated code still needs clean-up and assertions.

Yes: the request fixture (APIRequestContext) sends HTTP requests with the same assertions and reporting, useful for API tests or for setting up data before UI tests.

Register page.on('dialog', d => d.accept()) (or dismiss) before the action that opens it. By default Playwright dismisses dialogs automatically.

Set geolocation, locale, timezoneId and permissions in the context options or with test.use, so you can test location-based or localised behaviour.

1. AXPath by index
2. Bpage.$('#id')
3. Cpage.locator('div > span:nth-child(3)')
4. Dpage.getByRole('button', { name: 'Save' })Correct answer

Why: Role locators mirror how users find elements.

1. Aexpect(await el.isVisible()).toBe(true)
2. Bawait expect(locator).toBeVisible()Correct answer
3. Cassert(el)
4. Dexpect(el).toBeTruthy()

Why: Web-first assertions auto-retry; checking a boolean once does not.

1. AChromium, Firefox and WebKitCorrect answer
2. BOnly Safari
3. CInternet Explorer
4. DOnly Chrome

Why: One API drives all three engines.

1. ANeed manual waits
2. BRetry until the condition passes or times outCorrect answer
3. CRun once immediately
4. DOnly work on text

Why: They remove timing flakiness.

1. Apage.frameLocator()Correct answer
2. Bpage.iframe()
3. CswitchTo().frame()
4. Dpage.enterFrame()

Why: Locators then resolve inside it.

1. AReload the page
2. BClose other tabs
3. CNothing
4. DStart waiting for the popup eventCorrect answer

Why: Otherwise you may miss the event.

1. ADisable auth
2. BLog in inside every test
3. CstorageState saved after loginCorrect answer
4. DHard-coded cookies in code

Why: Saved storage state loads cookies and storage into new contexts.

1. Avideo: 'on'
2. Bdebug: true
3. Ctrace: 'off'
4. Dtrace: 'on-first-retry'Correct answer

Why: It keeps CI fast while capturing traces for failures.

1. Apage.route()Correct answer
2. Bpage.fetch()
3. Cpage.network()
4. Dpage.intercept()

Why: page.route lets you fulfil, modify or abort requests.

1. AA shared cookie jar
2. BThe same tab
3. CA fresh browser contextCorrect answer
4. DA new computer

Why: Contexts are like new incognito profiles.

1. Afs.copy()
2. Blocator.attach()
3. Clocator.setInputFiles()Correct answer
4. Dpage.upload()

Why: Works on file inputs.

1. AglobalSetup only
2. BbaseURL
3. Cuse.server
4. DwebServerCorrect answer

Why: It waits for the URL.

1. Aplaywright-a11y-only
2. Beslint-plugin-a11y
3. Clighthouse
4. D@axe-core/playwrightCorrect answer

Why: Scans the rendered page.

1. AInstall iOS
2. BSet userAgent only
3. CIt is impossible
4. DUse a devices['iPhone 15'] projectCorrect answer

Why: Sets viewport, touch and UA.

1. Anpm i chrome
2. Bapt install playwright
3. Cnpx playwright setup
4. Dnpx playwright install --with-depsCorrect answer

Why: Needed on CI machines.

1. A--parallel=4
2. B--split 4
3. C--workers=4
4. D--shard=1/4 (and 2/4, 3/4, 4/4)Correct answer

Why: Sharding divides tests between machines.

1. Anpx playwright show
2. Bnpx playwright open
3. Cnpm test --gui
4. Dnpx playwright test --uiCorrect answer

Why: UI mode lets you watch, filter and time-travel through tests.

1. AExtending timeouts only
2. BDefining custom fixturesCorrect answer
3. CAdding browsers
4. DExtending reports

Why: Custom fixtures provide reusable setup and teardown.

1. AIt disables tracing
2. BIt is deprecated in Python
3. CFixed waits are slow and still flakyCorrect answer
4. DIt crashes WebKit

Why: Wait for a condition, not a duration.

1. Acontext.freeze
2. Bpage.clockCorrect answer
3. Cpage.time
4. Djest.useFakeTimers

Why: Makes time-based tests deterministic.

1. ASkips the test
2. BIgnores the failure
3. CRetries forever
4. DRecords a failure and continuesCorrect answer

Why: The test still fails at the end.

1. AAccepted automatically
2. BThey block forever
3. CThey crash the test
4. DDismissed automaticallyCorrect answer

Why: Add a handler to accept.

1. AtoMatchAriaSnapshotCorrect answer
2. BtoHaveScreenshot
3. CtoBeVisible
4. DtoHaveURL

Why: Compares the ARIA tree.

1. ANamed steps in reports and tracesCorrect answer
2. BParallelism
3. CRetries
4. DScreenshots

Why: Easier to read failures.

1. Afs.watch
2. Bpage.waitForEvent('download')Correct answer
3. Cpage.waitForTimeout
4. Ddownload.wait()

Why: Start waiting before the click.

1. Anpx playwright write
2. Bnpx playwright init
3. Cnpx playwright codegenCorrect answer
4. Dnpx playwright record

Why: Codegen records interactions as test code.

1. AtoMatchSnapshot only for text
2. BtoHaveScreenshot()Correct answer
3. CtoLookSame()
4. DtoEqualImage()

Why: toHaveScreenshot does visual comparison.

1. ArequestCorrect answer
2. BbrowserName
3. CtestInfo
4. Dpage

Why: The request fixture is an APIRequestContext.

1. Alocale and timezoneIdCorrect answer
2. Blang and tz
3. Ci18n and clock
4. Dregion and zone

Why: Context options.

1. A--filter=smoke
2. B--grep @smokeCorrect answer
3. C--only smoke
4. D--tag smoke

Why: Tags are matched in titles.