playwright-best-practices

Guides writing, debugging, and structuring Playwright tests across E2E, API, and component scenarios.

Updated Aug 25, 2026
One-click install
npx skills add https://github.com/AliJ021/labelmod-core --skill playwright-best-practices-alij021
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: playwright-best-practices
Source: https://github.com/AliJ021/labelmod-core/tree/main/.claude/skills/playwright-best-practices
Command: npx skills add https://github.com/AliJ021/labelmod-core --skill playwright-best-practices-alij021

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires @playwright/test, @axe-core/playwright, zod, and includes references (resource) components.

What problem does it solve? Playwright test suites often suffer from flaky selectors, race conditions, poor structure, and slow CI pipelines. This Skill provides activity-based reference guidance covering the full Playwright testing lifecycle, so you write stable tests the first time and debug failures faster. ## Core Features & Use Cases - Activity-Based Reference Routing: A decision tree and lookup tables map your current task (writing E2E tests, fixing flaky tests, mocking APIs, configuring CI/CD) to the exact reference file you need. - Comprehensive Coverage: References span locators, assertions, Page Object Model, fixtures, authentication, API/GraphQL testing, accessibility (axe-core), visual regression, mobile emulation, WebSockets, security testing, Electron, browser extensions, and framework-specific guides for React, Angular, Vue, and Next.js. - Debugging & Infrastructure Guidance: Dedicated references for flaky test investigation, trace viewer usage, console error monitoring, parallel sharding, Docker, GitHub Actions, GitLab CI, and performance optimization. - Use Case: You are debugging a test that only fails in parallel CI runs. The decision tree routes you to flaky-tests.md, fixtures-hooks.md, and performance.md, which explain test isolation, worker-scoped fixtures, and sharding configuration. ## Quick Start Ask the AI to help you write or fix a Playwright test, for example by describing the failing test or the scenario you want to automate.

Frequently Asked Questions about playwright-best-practices

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

FAQPage Schema
How do I fix flaky Playwright tests?

Flaky Playwright tests usually stem from race conditions, shared state between tests, or missing auto-waiting assertions. Replace explicit waits with retrying assertions like expect(locator).toBeVisible(), ensure test isolation with fixtures, and use the trace viewer to inspect failures.

How to structure Playwright tests with Page Object Model?

Page Object Model encapsulates page locators and actions into reusable classes, keeping tests readable and maintainable. The skill covers when to choose POM versus fixtures, how to structure test suites, and how to embed test steps inside page objects for better reporting.

Should I use Playwright API tests or E2E tests?

Use API tests with the request fixture to validate status codes, response bodies, and business logic without launching a browser, which runs 10-100x faster. Reserve E2E tests for user-facing flows, error rendering, and navigation behavior.

Does Playwright support accessibility testing with axe-core?

Yes, Playwright integrates with @axe-core/playwright to run automated accessibility scans. You can analyze full pages or scoped regions, filter by WCAG tags, disable specific rules, and build a reusable fixture that fails tests on violations.

How do I run Playwright tests in CI with GitHub Actions?

The skill includes dedicated references for GitHub Actions, GitLab CI, Docker, and other providers. They cover browser installation, sharding for parallel execution, artifact uploads for traces and reports, and retry configuration for CI environments.

Why do Playwright tests fail only in parallel execution?

Parallel-only failures typically indicate shared mutable state, port conflicts, or test data collisions between workers. Use worker-scoped fixtures, unique test data per worker, and proper isolation instead of depending on execution order.