Name: Playwright Tutorial: Zero to CI
Availability: InStock

Nine questions on the decisions that matter most in a real Playwright suite. Each answer comes with a short explanation, so a wrong answer points you back to the right chapter.

1. A test clicks "Save" and then runs expect(await page.getByText('Saved').isVisible()).toBe(true). It fails about one run in ten. What is the best fix?

Add await page.waitForTimeout(2000) before the assertion Increase the global expect timeout to 30 seconds Replace it with await expect(page.getByText('Saved')).toBeVisible()

isVisible() answers immediately and never retries, so the generic toBe sees a snapshot. The web-first assertion retries until the text appears. Raising the timeout does nothing here, because nothing is waiting on it.

2. page.getByRole('checkbox', { name: 'Toggle Todo' }).check() throws a strict mode violation because three rows match. Which change best expresses the intent "complete the Pay rent item"?

Append .first() to the locator page.getByTestId('todo-item').filter({ hasText: 'Pay rent' }).getByRole('checkbox', { name: 'Toggle Todo' }) Switch to page.locator('input.toggle').nth(2)

Filtering the row by its content and then searching inside it targets the right item regardless of order. .first() and .nth() silently depend on list order, which is exactly what strictness is trying to stop you from relying on.

3. With fullyParallel: true and four workers, where should one-time "log in and save the session" work go?

A setup project that the browser projects list in dependencies, saving storageState to a file A test.beforeAll hook in each spec file A test.beforeEach hook that logs in through the form

beforeAll runs once per worker (and again after a worker restarts), and beforeEach logs in before every test. A setup project runs once before the dependent projects, shows up in the report and can record a trace.

4. A test failed on CI, passed on retry, and the job stayed green. Where do you look first?

Nowhere: it passed, so it is fine Raise retries to 5 so it never shows up again The trace recorded on the first retry, linked from the HTML report artifact, compared with the failing attempt

The report marks it flaky for a reason: something in the test does not wait for the right state. trace: 'on-first-retry' exists so that you have a trace for exactly this case.

5. Your project uses devices['iPhone 12']. What does that give you?

Safari running on a real iPhone Playwright's WebKit with an iPhone-sized viewport, user agent and touch emulation Chromium in a narrow window

Device presets are emulation: a browser engine plus viewport, user agent, scale factor and touch settings. That is great for responsive layout bugs, but it is not the real mobile browser on real hardware.

6. You shard a suite with --shard=1/4 ... --shard=4/4 across four GitHub jobs. How do you end up with a single HTML report?

Use the blob reporter on CI, upload each shard's blob-report, then run npx playwright merge-reports --reporter html in a job that needs the shards Upload all four playwright-report folders into the same artifact name It is not possible; you read four reports

Blob reports contain the full run data and are designed to be merged. Each HTML report is a self-contained site, so uploading four of them under one name just overwrites or collides.

7. A test only fails on CI and you were not watching. Which tool gives you DOM snapshots before and after every action, network calls and console output after the fact?

npx playwright codegen The Playwright Inspector with --debug The trace viewer, opened from the report or with npx playwright show-trace

Codegen records new tests and the Inspector needs you there while the test runs. A trace is a recording of a run that already happened, which is what a CI failure needs.

8. In a Playwright Test project that connects to a remote Firefox through connectOptions.wsEndpoint, what else must the project set?

Nothing; the endpoint decides everything browserName: 'firefox', so the runner connects with the matching Playwright engine headless: false

The runner calls connect() on the browser type named by the project's browserName, which defaults to chromium. Chrome and Edge use chromium, Firefox uses firefox, and Safari uses webkit.

9. Two parallel tests both log in as the same user and edit that user's profile. They pass alone and fail together. What is the root cause?

They share server-side state; browser contexts isolate cookies and storage, not your backend data Playwright shares one browser context between workers fullyParallel is broken and should be turned off

Every test already gets its own context, so nothing leaks in the browser. The collision is in the application's data. Give each worker its own account (for example keyed on testInfo.parallelIndex) or create unique data per test.

Where to go next#

If your suite is growing past a handful of files, the Page Object Model course shows how to structure locators and actions so the tests stay readable. To run what you built here across more browsers and operating systems, the Playwright documentation for TestingBot covers every language binding and option, and the official Playwright best practices guide is worth reading end to end.

Knowledge check

Where to go next#

You finished Playwright Tutorial: Zero to CI