--- title: 'Knowledge check | Playwright Tutorial: Zero to CI' description: 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… source_url: html: https://testingbot.com/resources/courses/playwright/knowledge-check md: https://testingbot.com/resources/courses/playwright/knowledge-check.md --- Course [Playwright Tutorial: Zero to CI](https://testingbot.com/resources/courses/playwright) Chapter 10 of 10 1. [1 Playwright Tutorial for Beginners](https://testingbot.com/resources/courses/playwright) 2. [2 Install Playwright and Run a First Test](https://testingbot.com/resources/courses/playwright/install-and-first-test) 3. [3 Locators: Find Elements the Way Users Do](https://testingbot.com/resources/courses/playwright/locators) 4. [4 Auto-Waiting and Web-First Assertions](https://testingbot.com/resources/courses/playwright/auto-waiting-and-assertions) 5. [5 Fixtures, Hooks and Logging In Once](https://testingbot.com/resources/courses/playwright/fixtures-hooks-and-authentication) 6. [6 Debugging: UI Mode, Trace Viewer, Codegen](https://testingbot.com/resources/courses/playwright/debugging-tests) 7. [7 Multiple Browsers, Workers and Sharding](https://testingbot.com/resources/courses/playwright/browsers-parallelism-and-sharding) 8. [8 Run Playwright in CI with GitHub Actions](https://testingbot.com/resources/courses/playwright/github-actions-ci) 9. [9 Run Your Playwright Suite on a Cloud Grid](https://testingbot.com/resources/courses/playwright/run-on-a-cloud-grid) 10. [10 Knowledge check](https://testingbot.com/resources/courses/playwright/knowledge-check) [Exit course](https://testingbot.com/resources/courses) Chapter 10 of 10 Beginner 6 min read Updated Nov 2026 # Knowledge check 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. Check answers ## Where to go next[#](https://testingbot.com#where-to-go-next) If your suite is growing past a handful of files, the [Page Object Model course](https://testingbot.com/resources/courses/page-object-model) 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](https://testingbot.com/support/web-automate/playwright) covers every language binding and option, and the official [Playwright best practices](https://playwright.dev/docs/best-practices) guide is worth reading end to end. [Previous · Chapter 9 Run Your Playwright Suite on a Cloud Grid](https://testingbot.com/resources/courses/playwright/run-on-a-cloud-grid) ## You finished Playwright Tutorial: Zero to CI Put what you learned into practice. Run your tests on 6100+ real browsers and physical iOS and Android devices. [Start free trial](https://testingbot.com/users/sign_up) [See pricing](https://testingbot.com/pricing) [Browse other courses](https://testingbot.com/resources/courses) ## Earn the TestingBot certification for this course Pass the exam and run the course suite on TestingBot. Free, with a public link you can add to LinkedIn. [How it works](https://testingbot.com/resources/courses/playwright/certification)