testing-playwright-e2e

Guides writing, reviewing, and debugging Playwright end-to-end tests with resilient locators and anti-flakiness practices.

3|3|Updated Apr 23, 2026
One-click install
npx skills add https://github.com/joaoguirunas/team-os --skill testing-playwright-e2e-joaoguirunas
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: testing-playwright-e2e
Source: https://github.com/joaoguirunas/team-os/tree/main/.claude/skills/testing-playwright-e2e
Command: npx skills add https://github.com/joaoguirunas/team-os --skill testing-playwright-e2e-joaoguirunas

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? End-to-end test suites often become flaky, slow, and brittle due to fragile selectors, hard-coded sleeps, and shared test state. This Skill provides a distilled set of Playwright best practices so teams can write stable E2E tests, review them against a QA checklist, and debug failures systematically. ## Core Features & Use Cases - Resilient Locators & Assertions: Enforces the getByRole/getByLabel/getByTestId priority order and web-first auto-retrying assertions, banning waitForTimeout and positional CSS selectors. - Test Isolation, Auth & Mocking: Covers per-test data seeding via API, storageState-based authentication setup projects, fixtures over classic page objects, and network mocking with page.route including error paths. - CI Configuration & Anti-Flakiness Loop: Provides a production playwright.config baseline (fullyParallel, retries, trace on-first-retry, sharding) plus a mandatory validation loop using --repeat-each=5 to prove stability. - Use Case: A QA engineer reviewing a pull request with new Playwright specs uses the built-in review checklist to flag waitForTimeout calls, order-dependent tests, and missing error-path coverage before approving the quality gate. ## Quick Start Review my Playwright test suite for flakiness risks and rewrite any fragile locators or assertions following best practices.

Frequently Asked Questions about testing-playwright-e2e

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write Playwright tests that are not flaky?▼

Use web-first assertions like toHaveText that auto-wait and retry, never call waitForTimeout, and wait for specific conditions such as URLs or network responses. Prove stability by running new specs with --repeat-each=5 and parallel workers before marking them done.

What locator strategy should I use in Playwright?▼

Follow the priority order: getByRole first, then getByLabel, getByPlaceholder, getByText, and getByTestId, reserving CSS or XPath selectors as a last resort. Locators tied to user-visible semantics survive DOM and style refactors.

How do I handle authentication in Playwright tests?▼

Log in once per role in a setup project and save the session with storageState, then reference that state file in dependent projects via playwright.config. Always load credentials from environment variables, never hardcode them in the repository.

Should I use page objects or fixtures in Playwright?▼

Prefer fixtures over classic page object inheritance because fixtures compose, handle setup and teardown, and provide typing. Keep page objects lightweight by encapsulating locators and actions only, leaving assertions visible inside the tests.

Why do my Playwright tests fail only in CI?▼

CI failures usually come from shared test data colliding under parallel workers, order-dependent tests, or timing assumptions hidden by faster local machines. Ensure each test seeds its own unique data via API and runs independently under fullyParallel mode.

When should I mock network requests in Playwright E2E tests?▼

Use real services for critical flows like checkout and authentication, but mock third-party integrations such as payment providers, email, or external OAuth with page.route. Also mock error responses to test failure paths, not just the happy path.