react-component-testing — SKILL.md

Variant: standard · When to use: the skill is invoked, runs to completion, returns a set-up + authored component-test layer (env + setupFiles + a worked test), control passes back to the caller.

Verified-at-forge versions. @testing-library/react 16.x · @testing-library/user-event 14.x · @testing-library/jest-dom 6.x · msw 2.x · vitest-axe 0.1.x (wraps axe-core) · @tanstack/react-query 5.x · vitest 3.x · jsdom. Teach version-agnostically; re-confirm exact majors + the happy-dom caveat against the maintainer docs at use (see references/sources.md).

Overview

Component tests are the middle layer of the test pyramid: above Vitest unit tests (pure logic — the vitest skill owns the runner) and below Playwright e2e (the playwright-best-practices skill). They render a real component tree and assert what a user sees and does, catching the integration between component + hooks + data-fetching that unit tests miss and that is far cheaper than driving every state through a browser e2e. Three tools compose into one cohesive layer: React Testing Library (RTL) renders and queries the tree the way a user perceives it and drives it with user-event; Mock Service Worker (MSW v2) mocks the network boundary so the app's real HTTP client and serialization run end-to-end; vitest-axe asserts the rendered output has no detectable accessibility violations. The load-bearing principle: the more your tests resemble the way your software is used, the more confidence they can give you — so you query by role/label, interact like a user, mock at the network not the module, and assert observable behavior, never implementation details. This skill owns the RTL + MSW + vitest-axe authoring layer and the component-test environment (setupFiles); it references — never re-teaches — the runner, the router harness, and static a11y lint.

When to activate

• ✅ Writing a component test for a Vite + React + TS SPA: render → interact → assert state → assert accessible.
• ✅ Setting up the component-test environment: the jsdom env, @vitejs/plugin-react, setupFiles (jest-dom matchers, RTL cleanup, the MSW server lifecycle, the vitest-axe extend).
• ✅ Mocking an HTTP/data-fetching boundary in a test — especially a generated @hey-api/openapi-ts (or openapi-fetch) client — so the real client is exercised and contract drift surfaces.
• ✅ Testing TanStack Query loading / empty / success / error states by varying the mocked network response.
• ✅ Testing a form: filling via user-event, asserting the request body an MSW handler captured, and asserting toHaveNoViolations.
• ✅ Adding a runtime accessibility assertion to an existing component test.