e2e-testing

Creates Playwright end-to-end tests for critical user journeys with accessibility checks.

Updated May 21, 2026
One-click install
npx skills add https://github.com/CagesThrottleUs/private-ai-harness --skill e2e-testing-cagesthrottleus
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: e2e-testing
Source: https://github.com/CagesThrottleUs/private-ai-harness/tree/main/skills/e2e-testing
Command: npx skills add https://github.com/CagesThrottleUs/private-ai-harness --skill e2e-testing-cagesthrottleus

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires @playwright/test, @axe-core/playwright.

What problem does it solve? Features often ship with unit and integration tests but no verification that the full user journey works from browser to database and back, leaving auth flows, permission boundaries, and rejection paths unverified at the system level. ## Core Features & Use Cases - Critical Journey Identification: Derives 5-10 critical user journeys from spec REQ-NNN acceptance criteria, prioritized by blast radius (auth, payments, CRUD, permissions), including rejection paths. - Playwright Setup & Patterns: Provides config, Page Object Model structure, semantic locator priority, auth fixtures with storageState, and anti-pattern rules (no hardcoded waits, no CSS selector coupling). - Accessibility Testing: Integrates axe-playwright for WCAG 2.1/2.2 AA checks on every critical page, with EU compliance support and a reusable checkAccessibility helper. - CI Integration: Adds an E2E job that runs against staging after deployment, with sharding, artifact uploads, and secrets management. - Use Case: After implementing a checkout feature, use this Skill to generate Playwright specs covering login, add-to-cart, payment success and decline paths, plus axe accessibility scans, then wire them into a post-deploy CI job. ## Quick Start Use the e2e-testing skill to write Playwright tests for the critical user journeys in my current feature spec and add accessibility checks.

Frequently Asked Questions about e2e-testing

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

FAQPage Schema
How do I write Playwright end-to-end tests for critical user journeys?

Identify 5-10 critical journeys from spec acceptance criteria, prioritized by blast radius: auth, payments, core CRUD, permissions, and search. Implement them with Page Object Model classes, semantic locators like getByRole, and auth fixtures, testing both success and rejection paths.

How to add accessibility testing to Playwright tests?

Install @axe-core/playwright and use AxeBuilder with WCAG tags like wcag2aa to scan pages inside your specs. Assert that results.violations is empty, and use the wcag22aa tag set when EU Accessibility Act compliance is required.

Playwright vs Cypress for E2E testing?

This Skill standardizes on Playwright, which surpassed Cypress in weekly npm downloads during 2024 and offers auto-waiting, fixtures, and built-in sharding. The provided config, fixtures, and CI templates are all Playwright-specific.

Can Playwright test APIs without a UI?

Yes, Playwright's request API supports API-only E2E tests covering the full request chain from auth through database and response. The Skill includes patterns for token-based authentication and verifying status codes like 201 and 401 against staging.

Why do Playwright tests become flaky in CI?

Flakiness usually comes from hardcoded waits like page.waitForTimeout, brittle CSS selectors, and tests depending on shared state from previous tests. Use semantic locators, wait for specific conditions, and keep each test independent.

When should E2E tests run in a CI pipeline?

E2E tests should run after the staging deployment job succeeds, not on every pull request, because they are slower than unit tests. Target under 15 minutes per run and use sharding when the suite grows beyond that.