react-testing

name	react-testing
description	Generates unit, component, and integration tests for plain React web projects (Vite, Create React App, or any non-Next.js React app) using Vitest or Jest with React Testing Library and MSW for network mocking. Use when the user asks to test a React component or hook, mentions .tsx/.jsx files, Vitest, Jest, React Testing Library, RTL, or MSW, in a project whose package.json has react and react-dom but not next or react-native. For Next.js projects (an app/ or pages/ directory, next.config.*), use nextjs-testing instead. For React Native/Expo projects, use react-native-testing instead.
license	MIT
compatibility	Requires Node.js and the project's existing package manager (npm/pnpm/yarn). Requires a package.json declaring react and react-dom without next.
metadata	{"platform":"react","report-source":"testing-methodologies-deep-research-report.txt Part 3 and Part 8"}
allowed-tools	Read, Write, Edit, Grep, Glob, Bash
paths	["**/*.tsx","**/*.jsx","package.json"]

React Testing

Writes unit, component, and integration tests for plain React (non-Next) projects, following the testing trophy model: a fat integration-test middle using real state + MSW-mocked network, a thin unit layer for pure logic only, and a small curated E2E layer. Writing the test files is the deliverable. Running the suite and verifying it — including the fault-injection self-check — is a separate, optional step this skill offers but never runs without being asked. See Step 6.

Progress checklist

Copy this into your response and check items off as you go:

- [ ] 1. Detect stack (scripts/detect_stack.sh)
- [ ] 2. Audit project structure and existing test conventions
- [ ] 3. Ask the user what to test (layer + scope) — do not assume
- [ ] 4. State the test plan explicitly
- [ ] 5. Generate tests following AAA, boundary-only (MSW) mocking
- [ ] 6. Report what was written; offer to run + verify — do not run yet
- [ ] 7. Only if asked: run tests, fault-injection self-check, report results

Step 1 — Detect stack

Run scripts/detect_stack.sh from the project root. It confirms this is a plain React web project (not Next.js, not React Native — the script errors out and points to nextjs-testing if next is present, or react-native-testing if react-native is present), and reports the existing test runner (Vitest/Jest), RTL/user-event, MSW, Playwright/Cypress, and test file convention (co-located *.test.tsx vs __tests__/).

If a test runner or mocking library is already in use, follow it even if a different tool is this skill's default recommendation. Never introduce a second, competing test runner into a project that already picked one.

Step 2 — Audit project structure

Before writing anything:

• Classify the target: a pure function (formatter, calculator, reducer) vs a component that fetches/renders/handles-errors vs a custom hook. Most components in a modern app are integration code, not meaningful "units" — default to a component/integration test for anything that renders, reserve pure unit tests for genuinely pure logic. See reference/test-layers.md.
• Match the existing test file convention exactly (co-located vs __tests__/) from Step 1.
• Flag critical paths — authentication, payment/billing, any data-write operation — for elevated rigor even if the user's request was narrower. State this flag out loud; do not silently expand scope.

Step 3 — Ask the user what to test (never assume)