e2e-testing

Use when you need end-to-end tests for critical user flows that unit tests can't cover — scaffolds Playwright/Cypress tests from the happy path through edge cases.

8 stars

Best use case

e2e-testing is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Use when you need end-to-end tests for critical user flows that unit tests can't cover — scaffolds Playwright/Cypress tests from the happy path through edge cases.

Teams using e2e-testing should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/e2e-testing/SKILL.md --create-dirs "https://raw.githubusercontent.com/drvoss/everything-copilot-cli/main/skills/testing/e2e-testing/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/e2e-testing/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How e2e-testing Compares

Feature / Agente2e-testingStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Use when you need end-to-end tests for critical user flows that unit tests can't cover — scaffolds Playwright/Cypress tests from the happy path through edge cases.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# End-to-End Testing

## When to Use

- Validating critical user journeys work from start to finish
- After major refactors that may break integration between components
- Before releases to verify the full system works together
- When unit tests pass but users report bugs in real workflows
- Setting up regression tests for frequently broken features

## Prerequisites

- Application can be started in a test/dev environment
- E2E test framework installed (Playwright, Cypress, Selenium, etc.)
- Test data and fixtures available or can be seeded
- Understanding of the most important user workflows

## Workflow

### 1. Identify Critical User Paths

Map the workflows that must always work:

```powershell
# Find existing E2E tests to understand what's covered
glob pattern="**/*.e2e.*"
glob pattern="**/e2e/**/*.{ts,js}"
glob pattern="**/cypress/**/*.{ts,js}"
glob pattern="**/playwright/**/*.{ts,js}"
```

Prioritize paths by business impact:

| Priority | Path | Example |
|----------|------|---------|
| 🔴 P0 | Revenue-critical | Signup → Purchase → Confirmation |
| 🔴 P0 | Authentication | Login → Access protected resource |
| 🟡 P1 | Core features | Create item → Edit → Delete |
| 🟡 P1 | Data integrity | Import → Transform → Export |
| 🟢 P2 | Secondary flows | Settings → Profile update |

### 2. Set Up the Test Environment

```powershell
# Start the application in test mode
$env:NODE_ENV="test"
npm run dev  # mode: async, detach: true

# Seed test data
npm run db:seed:test 2>&1

# Verify the app is running
curl -s http://localhost:3000/health
```

### 3. Write E2E Tests

**Playwright example:**

```typescript
// e2e/auth.spec.ts
import { test, expect } from '@playwright/test';

test.describe('Authentication Flow', () => {
  test('user can sign up and log in', async ({ page }) => {
    // Navigate to signup
    await page.goto('/signup');

    // Fill the form
    await page.fill('[name="email"]', 'test@example.com');
    await page.fill('[name="password"]', 'SecurePass123!');
    await page.click('button[type="submit"]');

    // Verify redirect to dashboard
    await expect(page).toHaveURL('/dashboard');
    await expect(page.locator('h1')).toContainText('Welcome');
  });

  test('shows error for invalid credentials', async ({ page }) => {
    await page.goto('/login');
    await page.fill('[name="email"]', 'wrong@example.com');
    await page.fill('[name="password"]', 'wrong');
    await page.click('button[type="submit"]');

    await expect(page.locator('.error')).toContainText('Invalid credentials');
    await expect(page).toHaveURL('/login');
  });
});
```

**API E2E example:**

```typescript
// e2e/api-workflow.spec.ts
import { test, expect } from '@playwright/test';

test.describe('API CRUD Workflow', () => {
  let itemId: string;

  test('create → read → update → delete', async ({ request }) => {
    // Create
    const createRes = await request.post('/api/items', {
      data: { name: 'Test Item', price: 29.99 },
    });
    expect(createRes.status()).toBe(201);
    const created = await createRes.json();
    itemId = created.id;

    // Read
    const getRes = await request.get(`/api/items/${itemId}`);
    expect(getRes.status()).toBe(200);
    expect((await getRes.json()).name).toBe('Test Item');

    // Update
    const updateRes = await request.put(`/api/items/${itemId}`, {
      data: { name: 'Updated Item' },
    });
    expect(updateRes.status()).toBe(200);

    // Delete
    const deleteRes = await request.delete(`/api/items/${itemId}`);
    expect(deleteRes.status()).toBe(204);

    // Verify deleted
    const verifyRes = await request.get(`/api/items/${itemId}`);
    expect(verifyRes.status()).toBe(404);
  });
});
```

### 4. Run E2E Tests

```powershell
# Playwright
npx playwright test 2>&1

# Cypress
npx cypress run 2>&1

# With specific test file
npx playwright test e2e/auth.spec.ts 2>&1

# Use task agent for clean output
```

```text
task agent_type: "task"
prompt: "Run 'npx playwright test' and report results. Show full output for any failures."
```

### 5. Debug Failures

```powershell
# Run with headed browser for visual debugging
npx playwright test --headed --debug e2e/auth.spec.ts

# View trace for failed test
npx playwright show-trace test-results/auth-trace.zip

# Screenshot on failure (auto-configured in playwright.config.ts)
```

### 6. Maintain Tests

```powershell
# Find flaky tests (tests that sometimes pass, sometimes fail)
# Run tests multiple times to detect flakiness
npx playwright test --repeat-each=3 2>&1 | Select-String "passed|failed|flaky"

# Find slow tests
npx playwright test --reporter=list 2>&1 | Sort-Object { [int]($_ -split '\s+')[-1] } -Descending | Select-Object -First 10
```

## Examples

### Setting Up Playwright from Scratch

```powershell
npm init playwright@latest 2>&1
# Generates: playwright.config.ts, e2e/ directory, package.json scripts
```

### CI Configuration

```yaml
# .github/workflows/e2e.yml
- name: Run E2E tests
  run: |
    npm run build
    npm start &
    npx wait-on http://localhost:3000
    npx playwright test
```

## Tips

- **Keep E2E tests focused** — test user journeys, not implementation details
- Use **page objects** or **fixtures** to reduce duplication across tests
- Run E2E tests in CI but not on every commit — they're slower than unit tests
- Use `test.beforeAll` to seed data and `test.afterAll` to clean up
- Prefer CSS selectors or test IDs (`data-testid`) over fragile XPath or text selectors
- If an E2E test is flaky, add explicit waits (`waitForSelector`) instead of arbitrary delays
- Use the `task` agent to run E2E suites — it keeps your context clean and summarizes results
- Capture screenshots and traces on failure for faster debugging

Related Skills

verification-before-completion

8
from drvoss/everything-copilot-cli

Use before claiming any task is done — run the exact command that proves the fix works, read the output, and only then report success.

using-git-worktrees

8
from drvoss/everything-copilot-cli

Use when you need multiple branches checked out at once — create isolated working directories for parallel development without cloning the repository repeatedly

triage

8
from drvoss/everything-copilot-cli

Use when a single issue needs structured triage — classify it, reproduce if needed, request missing information, and leave a durable brief or close-out note in the tracker.

to-issues

8
from drvoss/everything-copilot-cli

Use when a plan, spec, or PRD must become an actionable backlog — break it into thin dependency-aware issues that each deliver a verifiable vertical slice

sprint-workflow

8
from drvoss/everything-copilot-cli

Use when starting a new feature, refactor, or multi-step dev task — runs the full sprint cycle (Think → Plan → Build → Review → Test → Ship → Monitor) using Copilot CLI's plan/autopilot modes.

sprint-retro

8
from drvoss/everything-copilot-cli

Use at the end of a sprint to run a data-driven retrospective — analyzes session history and git metrics to surface what shipped, what slowed you down, and concrete improvements.

security-audit

8
from drvoss/everything-copilot-cli

Use when a codebase needs a formal security audit beyond a quick scan — applies OWASP Top 10 and STRIDE threat modeling from a CSO perspective to surface systemic vulnerabilities.

release

8
from drvoss/everything-copilot-cli

Use when a sprint or feature is complete and ready to ship — tags the version, generates GitHub Release notes, runs rollout or smoke verification, and publishes to npm/PyPI/Docker registries.

prompt-optimizer

8
from drvoss/everything-copilot-cli

Use when a rough prompt, vague idea, or task description needs to become a finished copy-pasteable prompt for a chat-based LLM - rewrite it into one ready-to-send prompt with no blanks, no placeholders, and a clear output shape.

outside-voice

8
from drvoss/everything-copilot-cli

Use when you need an independent second opinion before, during, or after implementation — run challenge, consult, or review mode in a direct builder-to-builder voice

llm-wiki

8
from drvoss/everything-copilot-cli

Use when research or domain knowledge keeps getting rediscovered across sessions — build a supplementary markdown wiki that compounds synthesized knowledge without replacing GitHub or committed project guidance

interview-me

8
from drvoss/everything-copilot-cli

Use when a request is underspecified and you need to discover what the user actually wants before writing a plan, spec, or code - ask one question at a time, attach your current hypothesis, and stop only after the intent is explicitly confirmed.