Our review

A skill that guides writing and running end-to-end web application tests with Playwright, including a systematic route audit and accessibility checks.

Strengths

Three-step audit approach (map, scan, test) with concrete guidance for discovering routes, API endpoints, and components in a codebase.
Ready-to-run script (playwright_runner.py) supporting screenshots and accessibility checks against a URL.
Actionable E2E principles: test prioritization, data-testid selectors, explicit waits, and recommended Playwright settings (retries, trace, screenshots).
Also covers visual regression and API testing, not just browser flows.

Limitations

Requires installing Playwright and Chromium first; the setup steps are not automated.
The bundled runner is minimal (one URL at a time) and does not generate test suites or visual baseline images.
The test organization section is cut off and no actual Playwright test code examples are included.

When to use it

Use it when setting up or structuring Playwright E2E tests, or when quickly auditing a live web app for functionality and accessibility.

When not to use it

Avoid it if you only need unit or component tests, or a turnkey CI integration with generated configuration.

Examples

Audit a live site

Audit https://example.com with scripts/playwright_runner.py: run the basic check, take a screenshot, and run the accessibility check. Then summarize the findings and list the issues by severity.

Map routes and plan E2E coverage

Scan this repo for all routes, API endpoints, and component directories, then propose a prioritized E2E test plan covering happy paths, auth flows, and critical business actions.

Set up Playwright config

Create a Playwright config with retries: 2 on CI, trace on-first-retry, screenshots on-failure, and video retain-on-failure, and scaffold a Page Object Model for our login flow.

name: webapp-testing description: End-to-end web application testing with Playwright. Use when writing E2E tests, setting up browser automation, running visual regression tests, or auditing a live web application for functionality and accessibility. allowed-tools: Read, Write, Edit, Glob, Grep, Bash

Web App Testing

Discover and test everything. Leave no route untested.

🔧 Runtime Scripts

Execute these for automated browser testing:

| Script | Purpose | Usage | | ------------------------------ | ------------------- | --------------------------------------------------------- | | scripts/playwright_runner.py | Basic browser test | python scripts/playwright_runner.py https://example.com | | | With screenshot | python scripts/playwright_runner.py <url> --screenshot | | | Accessibility check | python scripts/playwright_runner.py <url> --a11y |

Requires: Run python -m pip install playwright and python -m playwright install chromium

1. Deep Audit Approach

Discovery First

| Target | How to Find | | ------------- | ------------------------------- | | Routes | Scan app/, pages/, router files | | API endpoints | Grep for HTTP methods | | Components | Find component directories | | Features | Read documentation |

Systematic Testing

Map - List all routes/APIs
Scan - Verify they respond
Test - Cover critical paths

2. Testing Pyramid for Web

        /\          E2E (Few)
       /  \         Critical user flows
      /----\
     /      \       Integration (Some)
    /--------\      API, data flow
   /          \
  /------------\    Component (Many)
                    Individual UI pieces

3. E2E Test Principles

What to Test

| Priority | Tests | | -------- | ------------------------- | | 1 | Happy path user flows | | 2 | Authentication flows | | 3 | Critical business actions | | 4 | Error handling |

E2E Best Practices

| Practice | Why | | ---------------------------- | ------------------ | | Use data-testid | Stable selectors | | Wait for elements | Avoid flaky tests | | Clean state | Independent tests | | Avoid implementation details | Test user behavior |

4. Playwright Principles

Core Concepts

| Concept | Use | | ----------------- | ---------------------- | | Page Object Model | Encapsulate page logic | | Fixtures | Reusable test setup | | Assertions | Built-in auto-wait | | Trace Viewer | Debug failures |

Configuration

| Setting | Recommendation | | ----------- | ----------------- | | Retries | 2 on CI | | Trace | on-first-retry | | Screenshots | on-failure | | Video | retain-on-failure |

5. Visual Testing

When to Use

| Scenario | Value | | ----------------- | ------ | | Design system | High | | Marketing pages | High | | Component library | Medium | | Dynamic content | Lower |

Strategy

Baseline screenshots
Compare on changes
Review visual diffs
Update intentional changes

6. API Testing Principles

Coverage Areas

| Area | Tests | | -------------- | --------------------------- | | Status codes | 200, 400, 404, 500 | | Response shape | Matches schema | | Error messages | User-friendly | | Edge cases | Empty, large, special chars |

7. Test Organization

File Structure

tests/
├── e2e/           # Full user flows
├── integration/   # API, data
├── component/     # UI units
└── fixtures/      # Shared data

Naming Convention

| Pattern | Example | | ------------- | --------------------------- | | Feature-based | login.spec.ts | | Descriptive | user-can-checkout.spec.ts |

8. CI Integration

Pipeline Steps

Install dependencies
Install browsers
Run tests
Upload artifacts (traces, screenshots)

Parallelization

| Strategy | Use | | -------- | ------------------ | | Per file | Playwright default | | Sharding | Large suites | | Workers | Multiple browsers |

9. Anti-Patterns

| ❌ Don't | ✅ Do | | ------------------- | -------------- | | Test implementation | Test behavior | | Hardcode waits | Use auto-wait | | Skip cleanup | Isolate tests | | Ignore flaky tests | Fix root cause |

Remember: E2E tests are expensive. Use them for critical paths only.

E2E Web App Testing with Playwright

Recommended for