Knowledge Base / Cheat-sheets
Playwright Automation Testing
Locators & auto-waiting, web-first assertions, network/fixture mocking, cross-browser CI/CD & debugging, and a dedicated ecosystem/tools roundup - five sections you can filter and toggle as you verify them. Progress is saved on this device.
What this checklist covers
Core APIs & Locators
Finding and describing elements the way Playwright's engine is built to resolve them.
- page.goto() waits for the load event (or a configured waitUntil state) before the next action runs.
- Each test gets its own isolated BrowserContext by default, so cookies, storage, and cache never leak between tests.
- getByRole() queries the accessibility tree the same way a screen reader would, making it the recommended first choice.
- getByText(), getByLabel(), and getByPlaceholder() cover user-facing content without depending on markup structure.
- Locators are lazy descriptions, not live element handles - they re-query the DOM every time an action or assertion runs against them.
- Before clicking or typing, Playwright auto-waits for the element to be visible, stable, enabled, and not obscured - no manual wait needed.
Assertions & Auto-Waiting
Web-first assertions that retry against the live DOM instead of checking a single snapshot in time.
- expect(locator).toBeVisible(), .toHaveText(), and similar matchers retry automatically until they pass or the timeout elapses.
- Asserting directly on a locator (not a value pulled out with .textContent() first) is what gives an assertion its retry behavior.
- expect.soft() records a failure but keeps the test running, useful for collecting multiple independent checks in one pass.
- expect.poll() wraps an arbitrary function (not just a locator) in the same retry-until-pass behavior.
Network, Mocking & Auth
Controlling what the app talks to and skipping repetitive login flows.
- page.route() intercepts matching requests to fulfill, modify, or abort them without touching app code.
- page.waitForResponse() / waitForRequest() waits on a specific network event instead of a fixed timeout.
- The request fixture calls APIs directly, without a browser, for fast setup, teardown, or contract-style tests.
- Seeding or verifying state via the API before/after a UI test avoids re-testing the same setup through the UI every run.
- storageState() saves cookies and local storage after one login, so later tests can start already authenticated.
- A setup project (project dependency) runs the login once and shares the saved state across all other projects/workers.
Config, CI & Debugging
Running the suite for real: multi-browser projects, pipelines, and failure triage.
- playwright.config.ts centralizes baseURL, timeouts, retries, and reporters instead of scattering them across specs.
- The projects array runs the same suite across Chromium, Firefox, and WebKit (or device emulation profiles) from one config.
- Tests run in parallel workers by default; fullyParallel: true also parallelizes tests within a single file.
- --shard=1/3 style flags split one run across multiple CI machines to cut wall-clock time on large suites.
- trace: 'on-first-retry' (or 'on') captures a full trace - DOM snapshots, network, console - viewable in the Trace Viewer.
- PWDEBUG=1 or --debug opens the Playwright Inspector to step through a test action by action.
Playwright Ecosystem & Tooling
Built-in and third-party tooling that extends Playwright beyond the core test runner.
- npx playwright codegen records real browser interaction and generates a first-draft test, including selector suggestions.
- UI Mode (npx playwright test --ui) gives a watch-mode runner with time-travel debugging through each test step.
- @axe-core/playwright runs axe-core accessibility audits against any page inside a Playwright test.
- toHaveScreenshot() does built-in pixel-diff visual regression, with configurable masking for dynamic regions.
- Playwright Component Testing mounts and tests React/Vue/Svelte components in a real browser without a full app.
- @faker-js/faker or similar libraries generate randomized, realistic test data instead of static fixtures.
- The official GitHub Action (or first-party Docker image) pins browser versions so CI matches local runs exactly.
- The built-in HTML reporter and trace viewer usually replace the need for a third-party dashboard on small teams.