# Frontend Testing > Scaffold and advise on frontend testing for production readiness, mapped to the Front-End-Checklist Testing category (13 rules). Defines a testing pyramid (unit, integration, E2E, visual, a11y, cross-browser, real-device, perf-budget, mutation, error-monitoring, coverage, mocking, contract) and emits copy-pasteable configs: Playwright config + smoke specs, axe a11y (jest-axe / @axe-core/playwright), Pact contract tests, and a GitHub Actions perf-budget + coverage CI. Use when the user asks for 'frontend testing', 'test strategy', 'e2e', 'visual regression', 'playwright setup', 'playwright test', 'unit test', 'integration test', 'write tests', 'test generation', 'test coverage', 'regression test', 'perf budget CI', 'accessibility testing in CI', 'contract testing', 'mutation testing', 'настрой тесты фронта', or wants tests before a release. Scaffolds & advises only — does not run your full CI; you wire the configs in. Composes with frontend-perfection, frontend-a11y, frontend-performance, /frontend. - Skill: `bestdeejay-design/frontend-testing` (Agent Skill, multi-file: 9 files) - Install (CLI): `npx skillmds@latest add bestdeejay-design/frontend-testing` - Raw SKILL.md: https://api.skillmd.com/api/skills/bestdeejay-design/frontend-testing/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - License: MIT - Author: bestdeejay-design (https://skillmd.com/u/bestdeejay-design) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/bestdeejay-design/frontend-testing --- # frontend-testing Define and scaffold frontend testing for production readiness. Our other frontend skills (`frontend-perfection`, `frontend-a11y`, `frontend-performance`) audit a *built* site; they run ZERO tests. This skill closes that gap: it tells you *what* to test, *which* layer owns each concern, and *hands you the config* to wire into CI. It is a process/knowledge + scaffolding skill, not a runtime audit. ## The 13 Testing rules → pyramid layer Mapped 1:1 from the Front-End-Checklist "Testing" category. Each rule names the layer it belongs to and the reference file that scaffolds it. | # | Rule (verbatim priority) | Layer | Scaffold | |---|---|---|---| | 1 | Write unit tests [High] | Unit | your unit runner (Vitest/Jest) | | 2 | Write integration tests for key workflows [High] | Integration | your runner + MSW | | 3 | Implement end-to-end testing [High] | E2E | `references/playwright.config.ts`, `references/e2e-smoke.spec.ts` | | 4 | Use visual regression testing [Medium] | Visual | `references/visual-regression.md` | | 5 | Include accessibility testing [High] | A11y | `references/a11y-test.md` | | 6 | Test across all major browsers [High] | Cross-browser | `references/playwright.config.ts` (projects) | | 7 | Test on real mobile devices and viewports [High] | Real-device | `references/playwright.config.ts` (Mobile projects) | | 8 | Enforce performance budgets in CI [Medium] | Perf-budget | `references/ci-perf-budget.yml` | | 9 | Use mutation testing to measure how well tests detect bugs [Medium] | Mutation | Stryker config note | | 10 | Integrate real-time error monitoring in production [High] | Error-monitoring | Sentry note | | 11 | Maintain test coverage thresholds [Medium] | Coverage | `references/ci-perf-budget.yml` (coverage gate) | | 12 | Follow mocking best practices [Medium] | Mocking | mocking note | | 13 | Implement consumer-driven contract testing for API boundaries [Medium] | Contract | `references/contract-test.md` | ## Testing pyramid (shape, not just a list) ``` /\ E2E (few, critical journeys only) → Playwright / Cypress / \ Visual regression (key screens) → snapshot diff /----\ Cross-browser + real-device → Playwright projects / \ A11y (axe in CI) → jest-axe / @axe-core/playwright /--------\ Integration (key workflows) → Vitest/Jest + MSW / \ Unit (critical logic, many) → Vitest/Jest /____________\ Contract (API boundaries) → Pact ``` - **Unit** is the base: fast, many, no browser. Cover *critical functionality* only — not every getter. - **Integration** exercises units wired together (form + validation + state, or API route + query). Mock the *network boundary* with MSW, not the unit under test. - **E2E** covers only the 3–7 journeys that, if broken, are a sev-1 (login, checkout, signup, core nav). Everything else is waste. - **Visual / a11y / cross-browser / real-device** ride on the E2E run — same browser, extra assertions. Don't stand them up as separate suites. - **Contract** guards the frontend↔backend API boundary so a backend change can't silently break the UI. ## Decision guide: which test for which job | Symptom / question | Reach for | Why | |---|---|---| | "Is this pure function correct?" | Unit | Fastest feedback, no flake | | "Do these modules cooperate?" | Integration | Catches wiring bugs units miss | | "Can a real user complete the flow?" | E2E (Playwright) | Only layer that proves the journey | | "Did the layout shift unexpectedly?" | Visual regression | Pixel diff beats eyeballs | | "Is it usable by AT users?" | A11y (axe) | Automated WCAG subset in CI | | "Does it work in Firefox/Safari/Edge?" | Cross-browser projects | Engine differences are real | | "Does it break on a phone?" | Real-device / mobile emulation | Touch + viewport bugs | | "Did a backend change break the UI?" | Contract (Pact) | Fails before prod | | "Will my tests actually catch bugs?" | Mutation (Stryker) | Coverage % lies; mutations don't | | "Is it fast enough to ship?" | Perf budget in CI | Fails build on regression | | "What blew up in prod?" | Error monitoring (Sentry) | Post-deploy truth | Rule of thumb: **write the cheapest test that can fail for the right reason.** Don't E2E a pure function; don't unit-test a user journey. ## Composition with sibling skills - `frontend-perfection` — audits a *built* site (Lighthouse, contrast, tokens, a11y subset). This skill adds the *test suite* that prevents regressions the audit would otherwise catch late. Scaffold tests here first, then run `frontend-perfection` to verify the result stays green. - `frontend-a11y` — deep accessibility. This skill's `references/a11y-test.md` is the *CI gate* (axe in the pipeline); `frontend-a11y` is the *manual/expert* pass. They share axe-core; don't duplicate the audit — wire the gate. - `frontend-performance` — measures field/lab perf. This skill's `references/ci-perf-budget.yml` *fails the build* when budgets slip; `frontend-performance` tells you *why* and *how to fix*. - `/frontend` — orchestrator. Routes the testing/QA domain to this skill during a build or pre-release handoff. Do NOT reimplement perf/security/a11y audits here — point to the siblings. ## How to scaffold (workflow) 1. **Decide the layers you need.** Start from the pyramid; for a typical SPA: unit (Vitest) + integration (Vitest + MSW) + E2E (Playwright) + a11y gate + perf budget in CI. Add visual/contract/mutation when the cost is justified. 2. **Scaffold the configs** into the project with the bundled script — it copies the reference files deterministically and prints exactly what it wrote, so the run is *evidence* (a config that was never placed is a draft, not a scaffold): ```bash python3 scripts/scaffold.py --target /path/to/project --layers playwright,e2e,a11y,ci # expected: one "copied references/ -> " line per layer; # "Scaffolded N file(s) into "; exit 0 # exit 2 if --target does not exist; exit 1 if a source is missing ``` The script maps each layer to its reference file and destination (the reference files stay the source of truth if you prefer to place them by hand): - `playwright` → `references/playwright.config.ts` → `playwright.config.ts` - `e2e` → `references/e2e-smoke.spec.ts` → `e2e/e2e-smoke.spec.ts` - `a11y` → `references/a11y-test.md` → `e2e/a11y-test.md` - `visual` → `references/visual-regression.md` → `e2e/visual-regression.md` - `ci` → `references/ci-perf-budget.yml` → `.github/workflows/perf-budget.yml` - `contract` → `references/contract-test.md` → `tests/contract/contract-test.md` Copy only the layers you need; pass `--layers` to pick them. 3. **Install only what you use.** Baseline (E2E + a11y + unit): ```bash npm i -D @playwright/test @axe-core/playwright vitest @vitest/coverage-v8 msw npx playwright install --with-deps chromium firefox webkit ``` 4. **Wire the CI gate** (perf budget + coverage) from `references/ci-perf-budget.yml`. 5. **Run locally to prove the scaffold is green** (evidence gate below) before handing configs back. ## Evidence gates (show the command, show the expected shape) You must be able to demonstrate the scaffold runs, not just that files exist. **Unit / integration (Vitest):** ```bash npx vitest run --coverage # expected: ✓ N passed; coverage summary; exit 0 when ≥ threshold ``` **E2E (Playwright):** ```bash npx playwright test --project=chromium # expected: Running 6 tests using 1 worker; N passed; exit 0 # on failure: trace + screenshot retained (see config use:) ``` **A11y gate (axe in Playwright):** ```bash npx playwright test e2e/a11y.spec.ts # expected: no violations; exit 0. On violation: list of axe rule ids + nodes ``` **Mutation (Stryker) — critical logic only:** ```bash npx stryker run # expected: Mutation score ≥ your threshold (e.g. 80%); report shows killed/survived ``` **Perf budget (CI only, but locally reproducible):** ```bash npx lhci autorun --collect.url=http://localhost:3000 # expected: all budgets met; exit 0. Breach → non-zero exit fails the build ``` Report the exact command you ran, the real output (or its shape), and the exit code. A config that has never been executed is not "scaffolded" — it's a draft. ## Engagement / before-after report convention When you deliver a testing scaffold, write a short report: - **Input**: repo path, framework detected, which layers were missing. - **Added**: list of files created (with paths) and the layers they cover. - **Commands**: the exact commands to run each layer locally. - **CI**: what the workflow enforces (budgets, coverage threshold, browsers). - **Expected**: pass/fail shape per layer (from evidence gate). - **Not done (non-goals)**: we did not run your full CI, did not pick a backend provider for Pact, did not tune every threshold — those are the user's calls. - **Next**: which sibling skill to run next (perf / a11y / perfection). ## Constraints / non-goals - This skill **scaffolds & advises**. It does NOT run the user's full CI, deploy, or stand up their backend provider. It produces configs they wire in. - Framework-agnostic where possible: the Playwright example is the reference implementation; unit/integration snippets adapt to Vitest/Jest/Mocha. - Do NOT reimplement performance/security/a11y *audits* — delegate to the sibling skills. This skill owns the *testing/QA domain* only. - No external Front-End-Checklist MCP dependency; the 13 rules are inlined above. - Thresholds (coverage %, mutation score, Lighthouse numbers) are placeholders — set them with the user; don't ship arbitrary numbers as policy. ## References index - `references/playwright.config.ts` — multi-project config (devices, baseURL, trace). - `references/e2e-smoke.spec.ts` — critical-journey E2E example. - `references/visual-regression.md` — screenshot-diff approach + tooling. - `references/a11y-test.md` — jest-axe and @axe-core/playwright snippets. - `references/ci-perf-budget.yml` — GitHub Actions perf budget + coverage gate. - `references/contract-test.md` — Pact consumer-driven contract example.