react-testing

React Testing

Comprehensive React testing patterns for behavior-focused component tests, custom hook tests, accessibility assertions, and network-level mocking.

When to Activate

• Writing tests for React components, custom hooks, or pages
• Adding test coverage to legacy untested components
• Migrating from Enzyme or class-component-era patterns to React Testing Library
• Setting up Vitest or Jest for a new React project
• Mocking HTTP requests in tests
• Asserting accessibility violations
• Deciding which tests belong in RTL vs Playwright Component Testing vs full E2E

Core Principle

Test what the user sees and does, not implementation details.

A test should:

• Render the component with the same providers it has in production
• Interact with it via accessible queries (role, label) and userEvent
• Assert visible output and observable side effects (callback fired, request sent)

A test should NOT:

• Inspect component state, props passed to children, or which hooks were called
• Mock React itself or framework hooks
• Assert on the number of renders or DOM structure beyond what affects users

Library Choice

Pick one. Do not run RTL + Vitest AND Playwright CT in the same repo unless you have a clear lane separation.

Query Priority

React Testing Library exposes queries in three tiers — use top-down:

1. Accessible to everyone: getByRole, getByLabelText, getByPlaceholderText, getByText, getByDisplayValue
2. Semantic: getByAltText, getByTitle
3. Test IDs (escape hatch): getByTestId

// Best
screen.getByRole("button", { name: /save/i });

// OK for inputs
screen.getByLabelText("Email");

// Last resort
screen.getByTestId("save-btn");