Skills e2e-testing-patterns
📦

e2e-testing-patterns

Safe

Build Reliable End-to-End Test Suites

End-to-end tests catch critical bugs before users do, but flaky tests slow down deployment and erode confidence. This skill teaches proven patterns for building fast, reliable E2E test suites with Playwright and Cypress that improve code quality without slowing down your team.

Supports: Claude Codex Code(CC)
📊 71 Adequate
1

Download the skill ZIP

2

Upload in Claude

Go to Settings → Capabilities → Skills → Upload skill

3

Toggle on and start using

Test it

Using "e2e-testing-patterns". Create a custom Cypress command for user login

Expected outcome:

Generated a custom Cypress command that accepts email and password parameters, navigates to the login page, fills in credentials using data-testid selectors, clicks the submit button, and verifies successful redirect to the dashboard. Includes TypeScript type definitions for IDE autocomplete support.

Using "e2e-testing-patterns". How do I make this test less flaky?

Expected outcome:

Identified three flakiness sources: fixed timeout waits should be replaced with conditional waits, CSS class selectors should use data-testid attributes, and parallel tests share state through global variables. Provided specific code changes with proper waitForLoadState, role-based selectors, and isolated test fixtures.

Using "e2e-testing-patterns". Set up visual regression testing with Playwright

Expected outcome:

Created a visual regression test pattern that captures full-page screenshots, handles different viewport sizes, excludes dynamic content like timestamps, and uses pixel difference thresholds to reduce false positives. Includes baseline generation workflow and CI integration steps.

Security Audit

Safe
v5 • 1/21/2026

This skill provides educational content for end-to-end testing patterns with Playwright and Cypress. All static findings are false positives: weak crypto detections are from filename patterns, backtick executions are code examples in documentation, environment variable access is legitimate test configuration, and hardcoded URLs are localhost test endpoints. No security risks identified.

2
Files scanned
1,286
Lines analyzed
0
findings
5
Total audits
No security issues found
Audited by: claude View Audit History →

Quality Score

38
Architecture
100
Maintainability
87
Content
31
Community
100
Security
87
Spec Compliance

What You Can Build

QA Engineer Building Test Automation

A quality assurance engineer needs to establish E2E testing standards for a new project. They use this skill to generate Page Object Models, set up CI/CD integration, and implement reliable waiting strategies that reduce test flakiness.

Frontend Developer Testing User Flows

A frontend developer wants to add E2E tests for critical user workflows like authentication and checkout. They use this skill to create network mocking patterns, custom fixtures, and accessibility tests that catch regressions early.

Tech Lead Establishing Testing Standards

A technical lead needs to establish E2E testing best practices across multiple teams. They use this skill to document selector strategies, parallel testing patterns, and debugging approaches that improve test suite maintainability.

Try These Prompts

Generate Page Object Model
Create a Page Object Model for a login page with email, password fields, and error handling using Playwright
Debug Flaky Test
Review this test and suggest fixes for flaky behavior caused by timing issues and race conditions
Mock API Responses
Create network interception patterns to mock API failures and edge cases for a user profile page
Implement Parallel Testing
Design a sharding strategy to run 200 E2E tests across 4 CI workers with optimal distribution

Best Practices

  • Use semantic selectors like getByRole and getByLabel instead of CSS classes to create stable tests that survive UI refactoring
  • Implement proper waiting strategies with conditional waits and assertions rather than fixed timeouts to eliminate flaky tests
  • Keep tests independent with isolated fixtures and cleanup to enable parallel execution and reliable test runs

Avoid

  • Using fixed timeouts like waitForTimeout instead of waiting for specific conditions leads to unreliable tests that fail intermittently
  • Testing implementation details or internal state instead of user-visible behavior creates brittle tests that break with refactoring
  • Sharing state between tests or relying on test execution order prevents parallel execution and causes cascading failures

Frequently Asked Questions

Should I use Playwright or Cypress for E2E testing?
Both are excellent choices. Playwright offers better multi-browser support, faster execution, and native TypeScript support. Cypress provides a better debugging experience and simpler API for beginners. Choose based on your team's needs and existing tooling.
How many E2E tests should I write compared to unit tests?
Follow the testing pyramid: many unit tests, fewer integration tests, and only critical path E2E tests. E2E tests are slow and expensive, so focus on user workflows that would cause major business impact if broken, like authentication, checkout, and data submission.
How do I fix flaky tests that fail randomly in CI?
Replace fixed timeouts with conditional waits, use stable selectors like data-testid instead of CSS classes, ensure tests are independent without shared state, and verify network requests complete before making assertions. The skill provides specific patterns for each scenario.
Can I use this skill with testing frameworks other than Playwright and Cypress?
The patterns and principles apply broadly to E2E testing, but code examples are specific to Playwright and Cypress. Concepts like Page Object Model, waiting strategies, and network mocking translate to other frameworks with syntax adjustments.
How do I speed up my E2E test suite in CI pipelines?
Use parallel execution with sharding to distribute tests across workers, mock external APIs to avoid network delays, run tests in headless mode, and only test critical paths with E2E while moving edge cases to faster integration tests.
Should I test accessibility requirements with E2E tests?
Yes, integrating accessibility testing with tools like axe-core in your E2E suite ensures accessibility is validated with real user interactions. This catches issues that static analysis might miss, like keyboard navigation and screen reader compatibility.

Developer Details

File structure

📄 SKILL.md