playwright-best-practices

Guides writing, debugging, and maintaining Playwright end-to-end, API, and component tests.

Updated Jul 9, 2026
One-click install
npx skills add https://github.com/octanutri-clin/octaclin --skill playwright-best-practices-octanutri-clin
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: playwright-best-practices
Source: https://github.com/octanutri-clin/octaclin/tree/main/.agents/skills/playwright-best-practices
Command: npx skills add https://github.com/octanutri-clin/octaclin --skill playwright-best-practices-octanutri-clin

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, brittle waits, poor structure, and slow CI pipelines. This Skill provides a comprehensive, activity-indexed reference of proven Playwright patterns 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, setting up CI/CD, mocking APIs) directly to the right reference file. - Broad Coverage: Covers E2E, component, API, visual regression, accessibility (axe-core), security, Electron, browser extension, mobile, and multi-user testing, plus framework guides for React, Angular, Vue, and Next.js. - Infrastructure Guidance: Includes patterns for GitHub Actions, GitLab CI, Docker, sharding, parallel execution, reporting, global setup/teardown, and test tags/annotations. - Use Case: Your Angular app's login test flakes only in CI with multiple workers. The decision tree routes you to flaky-tests.md and performance.md, where you find test isolation and fixture patterns that eliminate the shared-state race condition. ## Quick Start Ask the agent to help you write or fix a Playwright test, for example: write an E2E test for the checkout flow using role-based locators and proper auto-waiting assertions.

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 hard-coded waits, shared state between tests, or race conditions. Replace waitForTimeout with auto-retrying assertions like expect(locator).toBeVisible(), isolate test data per worker using fixtures, and use the trace viewer to diagnose timing issues.

How do I structure Playwright tests with Page Object Model?

Page Object Model in Playwright encapsulates page locators and actions in classes, keeping tests readable and maintainable. The skill's references cover 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 is 10-100x faster. Reserve E2E tests for user-facing flows, and seed E2E test data via API calls for speed and reliability.

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, exclude known issues, and gate CI pipelines on violation counts.

How do I run Playwright tests in GitHub Actions CI?

Playwright runs in GitHub Actions by installing browsers with npx playwright install --with-deps and executing tests in a CI workflow. The skill covers sharding for parallel execution, retry configuration, trace and screenshot artifacts on failure, and merging reports across shards.

Why do my Playwright tests pass locally but fail in CI?

CI failures typically come from missing environment variables, different base URLs, unseeded databases, or resource-constrained runners causing timeouts. Use process.env for configuration, globalSetup for seeding, retries in CI, and unique test data identifiers to avoid collisions.