home / skills / vudovn / antigravity-kit / webapp-testing

webapp-testing skill

safe

This skill helps you implement comprehensive web app testing by guiding E2E, API, and visual validation with Playwright-based practices.

npx playbooks add skill vudovn/antigravity-kit --skill webapp-testing

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

Files (2)

SKILL.md

3.7 KB

---
name: webapp-testing
description: Web application testing principles. E2E, Playwright, deep audit strategies.
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:** `pip install playwright && 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

1. **Map** - List all routes/APIs
2. **Scan** - Verify they respond
3. **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

1. Install dependencies
2. Install browsers
3. Run tests
4. 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.

Overview

This skill teaches practical web application testing principles with an emphasis on end-to-end strategies, Playwright usage, and deep audit techniques. It guides discovery of routes and APIs, organizes test suites, and prioritizes what to cover to keep E2E test suites high-value and maintainable. Learn how to configure Playwright for reliable CI runs and add visual and API testing to your coverage.

How this skill works

The approach begins with discovery: mapping routes, endpoints, components, and features. It then scans and verifies those targets before writing focused tests for critical user flows. Playwright patterns like the Page Object Model, fixtures, retries, and traces are recommended to reduce flakiness and improve debugging. Visual and API testing strategies supplement E2E tests to widen coverage while controlling test cost.

When to use it

When onboarding to a new web app to identify all user routes and APIs
Before shipping critical flows like login, checkout, or payments
When CI shows intermittent flakiness and you need robust Playwright config
To add visual regression checks for design systems or marketing pages
When validating API contracts, error handling, and edge cases

Best practices

Discover and map routes/APIs first to avoid missing surface area
Prioritize happy paths and critical business actions for E2E tests
Use stable selectors (data-testid), auto-waiting, and isolate test state
Apply Page Object Model and fixtures to encapsulate behavior and reuse setup
Configure retries, traces, and artifact uploads for CI debugging
Prefer API and component tests for broad coverage; reserve E2E for critical paths

Example use cases

Run a Playwright script to capture screenshots and accessibility reports for a page
Audit an app by scanning routes, verifying responses, and listing untested endpoints
Implement visual regression for a component library with baseline screenshots
Create CI steps to install browsers, run tests with retries, and upload traces
Write API tests that assert status codes, response shapes, and edge case behavior

FAQ

How many E2E tests should I keep?

Keep E2E tests few and focused on critical user journeys; rely on component and API tests for broader coverage.

How do I reduce flaky Playwright tests?

Use stable selectors, auto-wait features, clean test state, retries on CI, and enable traces to diagnose failures.