What this prompt does
This prompt builds a complete testing strategy for a React app, not just a few sample tests. It produces a testing-pyramid plan, Vitest and React Testing Library configuration, shared test utilities, example tests for specific component types, MSW handlers for API mocking, accessibility tests with jest-axe, snapshot tests, custom matchers, and CI pipeline config. The guiding principle is testing behavior rather than implementation, so refactors don't shatter the suite.
The variables tailor the plan to your codebase. [app_type] and [component_count] set scale and inform the unit/integration/e2e ratio. [component_types] lists the exact components to write example tests for — forms with validation, data tables with sorting, modals, authenticated pages — so the examples are relevant. [snapshot_targets] picks where snapshot testing actually helps (email templates, PDF reports), and [ci_platform] (GitHub Actions) determines the pipeline config. MSW for API mocking and jest-axe for accessibility are the two additions that catch the bugs most worth catching, and coverage thresholds plus pre-commit hooks keep the discipline enforced.
When to use it
- Establishing a testing approach for a React codebase that has little or none
- Deciding the right unit/integration/e2e balance for your app's size
- Setting up MSW so tests mock the network instead of real API calls
- Adding accessibility checks to the suite with jest-axe
- Writing reference tests for tricky components like sortable tables and modals
- Wiring coverage thresholds and pre-commit hooks into CI
Example output
You get a written testing-pyramid plan with a recommended ratio, Vitest plus React Testing Library config, custom test utilities (a render wrapped in providers, mock factories), example tests for each of your [component_types], MSW request handlers, jest-axe accessibility tests, snapshot tests targeting [snapshot_targets], custom matchers, and a [ci_platform] pipeline file. Coverage thresholds and pre-commit hooks are included. The examples test behavior — what the user sees and does — rather than internal state, so they survive refactors.
Pro tips
- List the real
[component_types]you struggle to test (forms, sortable tables, modals) so the examples address your actual pain, not toy components - Keep snapshot tests narrow —
[snapshot_targets]like email templates and PDFs benefit; snapshotting whole interactive pages just creates brittle churn - Lean on the test-behavior-not-implementation principle; if a test breaks on a refactor that didn't change behavior, it was testing the wrong thing
- Use MSW handlers as the single source of mocked API responses so tests and dev mocks stay consistent
- Set coverage thresholds you'll actually keep; an unrealistic bar gets disabled, which is worse than a modest one that holds
- Verify the
[ci_platform]config matches your runner's syntax before committing it
