home / skills / wesleysmits / agent-skills / e2e-testing-patterns

e2e-testing-patterns skill

/.agent/skills/e2e-testing-patterns

This skill helps you design, implement, and maintain reliable end-to-end tests with Playwright and Cypress to catch regressions fast.

This is most likely a fork of the e2e-testing-patterns skill from xfstudio
npx playbooks add skill wesleysmits/agent-skills --skill e2e-testing-patterns

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
4.5 KB
---
name: implementing-e2e-testing
description: Master end-to-end testing with Playwright and Cypress to build reliable test suites that catch bugs, improve confidence, and enable fast deployment. Use when implementing E2E tests, debugging flaky tests, or establishing testing standards.
---

# E2E Testing Patterns

Build reliable, fast, and maintainable end-to-end test suites that provide confidence to ship code quickly and catch regressions before users do.

## When to Use This Skill

- Implementing end-to-end test automation
- Debugging flaky or unreliable tests
- Testing critical user workflows
- Setting up CI/CD test pipelines
- Testing across multiple browsers
- Validating accessibility requirements
- Testing responsive designs
- Establishing E2E testing standards

## Core Concepts

### 1. E2E Testing Fundamentals

**What to Test with E2E:**

- Critical user journeys (login, checkout, signup)
- Complex interactions (drag-and-drop, multi-step forms)
- Cross-browser compatibility
- Real API integration
- Authentication flows

**What NOT to Test with E2E:**

- Unit-level logic (use unit tests)
- API contracts (use integration tests)
- Edge cases (too slow)
- Internal implementation details

### 2. Test Philosophy

**The Testing Pyramid:**

```
        /\
       /E2E\         ← Few, focused on critical paths
      /─────\
     /Integr\        ← More, test component interactions
    /────────\
   /Unit Tests\      ← Many, fast, isolated
  /────────────\
```

**Best Practices:**

- Test user behavior, not implementation
- Keep tests independent
- Make tests deterministic
- Optimize for speed
- Use data-testid, not CSS selectors

## Framework Patterns

For detailed Playwright and Cypress code examples including:

- Page Object Model
- Fixtures for test data
- Waiting strategies
- Network mocking and interception
- Custom commands
- Visual regression testing
- Parallel testing with sharding
- Accessibility testing

👉 **[examples/test-patterns.md](examples/test-patterns.md)**

## Best Practices

1. **Use Data Attributes**: `data-testid` or `data-cy` for stable selectors
2. **Avoid Brittle Selectors**: Don't rely on CSS classes or DOM structure
3. **Test User Behavior**: Click, type, see - not implementation details
4. **Keep Tests Independent**: Each test should run in isolation
5. **Clean Up Test Data**: Create and destroy test data in each test
6. **Use Page Objects**: Encapsulate page logic
7. **Meaningful Assertions**: Check actual user-visible behavior
8. **Optimize for Speed**: Mock when possible, parallel execution

```typescript
// ❌ Bad selectors
cy.get(".btn.btn-primary.submit-button").click();
cy.get("div > form > div:nth-child(2) > input").type("text");

// ✅ Good selectors
cy.getByRole("button", { name: "Submit" }).click();
cy.getByLabel("Email address").type("[email protected]");
cy.get('[data-testid="email-input"]').type("[email protected]");
```

## Common Pitfalls

- **Flaky Tests**: Use proper waits, not fixed timeouts
- **Slow Tests**: Mock external APIs, use parallel execution
- **Over-Testing**: Don't test every edge case with E2E
- **Coupled Tests**: Tests should not depend on each other
- **Poor Selectors**: Avoid CSS classes and nth-child
- **No Cleanup**: Clean up test data after each test
- **Testing Implementation**: Test user behavior, not internals

## Debugging Failing Tests

```typescript
// Playwright debugging
// 1. Run in headed mode
npx playwright test --headed

// 2. Run in debug mode
npx playwright test --debug

// 3. Use trace viewer
await page.screenshot({ path: 'screenshot.png' });
await page.video()?.saveAs('video.webm');

// 4. Add test.step for better reporting
test('checkout flow', async ({ page }) => {
    await test.step('Add item to cart', async () => {
        await page.goto('/products');
        await page.getByRole('button', { name: 'Add to Cart' }).click();
    });

    await test.step('Proceed to checkout', async () => {
        await page.goto('/cart');
        await page.getByRole('button', { name: 'Checkout' }).click();
    });
});

// 5. Inspect page state
await page.pause();  // Pauses execution, opens inspector
```

## Resources

- **references/playwright-best-practices.md**: Playwright-specific patterns
- **references/cypress-best-practices.md**: Cypress-specific patterns
- **references/flaky-test-debugging.md**: Debugging unreliable tests
- **assets/e2e-testing-checklist.md**: What to test with E2E
- **assets/selector-strategies.md**: Finding reliable selectors
- **scripts/test-analyzer.ts**: Analyze test flakiness and duration

Overview

This skill teaches how to implement reliable end-to-end testing using Playwright and Cypress to catch regressions, speed up releases, and increase confidence in shipping. It focuses on testing critical user journeys, avoiding flaky tests, and integrating E2E suites into CI/CD pipelines. Practical patterns, debugging techniques, and selector strategies are included to make tests fast and maintainable.

How this skill works

The skill inspects common E2E pain points and provides patterns: page object models, fixtures, waiting strategies, network mocking, and visual regression tooling. It shows how to write deterministic tests with stable selectors (data-testid, role, label), how to run tests in parallel, and how to debug flaky failures using headed mode, traces, screenshots, and the Playwright inspector. It also describes when to mock API calls vs. use real integrations to balance speed and realism.

When to use it

  • Implementing end-to-end automation for critical user journeys
  • Debugging flaky or intermittent test failures
  • Establishing E2E testing standards and team conventions
  • Setting up CI/CD test pipelines and parallel/shard strategies
  • Validating cross-browser, responsive, or accessibility requirements

Best practices

  • Use data attributes (data-testid, data-cy) or ARIA roles for stable selectors
  • Test user behavior not implementation details — click, type, assert visible text
  • Keep tests independent; create and teardown test data per test
  • Mock slow or unreliable external APIs to speed tests; use real integrations selectively
  • Adopt Page Object or helper layers to encapsulate page interactions
  • Use meaningful assertions and avoid brittle CSS or nth-child selectors

Example use cases

  • Build a focused E2E suite covering login, signup, checkout and critical workflows
  • Convert flaky Cypress tests by replacing fixed timeouts with proper waiting strategies and network stubbing
  • Set up Playwright parallel test runs and sharding in CI to reduce feedback time
  • Add accessibility and visual regression checks to catch UI regressions early
  • Create fixtures and factory data to consistently seed and clean test state between runs

FAQ

Should I write E2E tests for every feature?

No. Focus E2E tests on critical user journeys and high-risk flows. Use unit and integration tests for business logic and API contract validation.

How do I reduce flakiness?

Avoid fixed waits, rely on explicit waits for elements or network responses, use stable selectors, isolate tests, and mock unreliable external services.