
Playwright Testing
Stand up reliable Playwright E2E tests with Page Objects, cross-browser projects, auth setup, and CI-ready reporters when writing or debugging browser tests.
Overview
Playwright Testing is an agent skill for the Ship phase that guides cross-browser Playwright E2E setup, configuration, and debugging for web apps.
Install
npx skills add https://github.com/alinaqi/claude-bootstrap --skill playwright-testingWhat is this skill?
- Install paths for new (`npm init playwright@latest`) and existing (`@playwright/test`) projects
- Reference `playwright.config.ts` with parallel runs, CI retries, trace/screenshot/video on failure
- Multi-project layout including dedicated auth `setup` testMatch
- Cross-browser `devices` projects aligned with Playwright docs
- When-to-use trigger: writing or debugging E2E tests with Playwright
- CI configuration uses 2 retries when `process.env.CI` is set
- Reporter stack includes html, list, and github (in CI) variants
Adoption & trust: 1.8k installs on skills.sh; 691 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need trustworthy browser tests but lack a consistent Playwright layout, CI reporters, and auth setup pattern.
Who is it for?
Indie SaaS or API-backed frontends where you want parallel E2E with traces and failure artifacts before shipping.
Skip if: Pure unit-test-only codebases or mobile-native apps that do not target Playwright’s web automation model.
When should I use this skill?
When writing or debugging E2E tests with Playwright (paths: e2e, *.spec.ts, playwright, playwright.config).
What do I get? / Deliverables
You get an installable Playwright stack, opinionated config, and test-structure guidance aligned with official best practices for local and CI runs.
- `playwright.config.ts` tuned for local and CI
- E2E spec files under `e2e/` with optional `.setup.ts` auth project
- Installed `@playwright/test` browsers via `npx playwright install`
Recommended Skills
Journey fit
How it compares
Opinionated Playwright bootstrap skill—not a generic Jest/Vitest unit-testing cheat sheet.
Common Questions / FAQ
Who is playwright-testing for?
Solo builders and small teams maintaining web apps who want Playwright E2E with CI-friendly config and Page Object discipline.
When should I use playwright-testing?
In the Ship testing subphase when adding `e2e` specs, tuning `playwright.config.ts`, or debugging flaky cross-browser failures.
Is playwright-testing safe to install?
It recommends standard npm installs and local test runs; review the Security Audits panel on this Prism page and pin `@playwright/test` versions in your repo.
SKILL.md
READMESKILL.md - Playwright Testing
# Playwright E2E Testing Skill For end-to-end testing of web applications with Playwright - cross-browser, fast, reliable. **Sources:** [Playwright Best Practices](https://playwright.dev/docs/best-practices) | [Playwright Docs](https://playwright.dev/docs/intro) | [Better Stack Guide](https://betterstack.com/community/guides/testing/playwright-best-practices/) --- ## Setup ### Installation ```bash # New project npm init playwright@latest # Existing project npm install -D @playwright/test npx playwright install ``` ### Configuration ```typescript // playwright.config.ts import { defineConfig, devices } from '@playwright/test'; export default defineConfig({ testDir: './e2e', fullyParallel: true, forbidOnly: !!process.env.CI, retries: process.env.CI ? 2 : 0, workers: process.env.CI ? 1 : undefined, reporter: [ ['html'], ['list'], process.env.CI ? ['github'] : ['line'], ], use: { baseURL: process.env.BASE_URL || 'http://localhost:3000', trace: 'on-first-retry', screenshot: 'only-on-failure', video: 'retain-on-failure', }, projects: [ // Auth setup - runs once before all tests { name: 'setup', testMatch: /.*\.setup\.ts/ }, { name: 'chromium', use: { ...devices['Desktop Chrome'] }, dependencies: ['setup'], }, { name: 'firefox', use: { ...devices['Desktop Firefox'] }, dependencies: ['setup'], }, { name: 'webkit', use: { ...devices['Desktop Safari'] }, dependencies: ['setup'], }, // Mobile viewports { name: 'mobile-chrome', use: { ...devices['Pixel 5'] }, dependencies: ['setup'], }, { name: 'mobile-safari', use: { ...devices['iPhone 12'] }, dependencies: ['setup'], }, ], // Start dev server before tests webServer: { command: 'npm run dev', url: 'http://localhost:3000', reuseExistingServer: !process.env.CI, timeout: 120 * 1000, }, }); ``` --- ## Project Structure ``` project/ ├── e2e/ │ ├── fixtures/ │ │ ├── auth.fixture.ts # Auth fixtures │ │ └── test.fixture.ts # Extended test with fixtures │ ├── pages/ │ │ ├── base.page.ts # Base page object │ │ ├── login.page.ts # Login page object │ │ ├── dashboard.page.ts # Dashboard page object │ │ └── index.ts # Export all pages │ ├── tests/ │ │ ├── auth.spec.ts # Auth tests │ │ ├── dashboard.spec.ts # Dashboard tests │ │ └── checkout.spec.ts # Checkout flow tests │ ├── utils/ │ │ ├── helpers.ts # Test helpers │ │ └── test-data.ts # Test data factories │ └── auth.setup.ts # Global auth setup ├── playwright.config.ts └── .auth/ # Stored auth state (gitignored) ``` --- ## Locator Strategy (Priority Order) Use locators that mirror how users interact with the page: ```typescript // ✅ BEST: Role-based (accessible, resilient) page.getByRole('button', { name: 'Submit' }) page.getByRole('textbox', { name: 'Email' }) page.getByRole('link', { name: 'Sign up' }) page.getByRole('heading', { name: 'Welcome' }) // ✅ GOOD: User-facing text page.getByLabel('Email address') page.getByPlaceholder('Enter your email') page.getByText('Welcome back') page.getByTitle('Profile settings') // ✅ GOOD: Test IDs (stable, explicit) page.getByTestId('submit-button') page.getByTestId('user-avatar') // ⚠️ AVOID: CSS selectors (brittle) page.locator('.btn-primary') page.locator('#submit') // ❌ NEVER: XPath (extremely brittle) page.locator('//div[@class="container"]/button[1]') ``` ### Chaining Locators ```typescript // Narrow down to specific se