react-testing

Prioritize by confidence-per-cost: write browser tests for critical user flows, unit tests for non-trivial business logic, and component tests only for complex shared components. Skip tests for trivial functions, styling, and refactors without behavior changes.

Use Playwright for end-to-end flows in a real browser, which gives the highest confidence. Use React Testing Library with Vitest for unit tests of logic and the few component tests worth keeping, since jsdom lacks real layout and many Web APIs.

Component tests are worth it for complex interactive components like multi-selects or drag-and-drop, and for shared design-system components with wide blast radius. Avoid them for page-level components and presentational components, which browser tests cover better.

jsdom is not a real browser: it lacks layout, real event bubbling, intersection observers, and many Web APIs, so tests can pass in jsdom but fail in production. Heavy mocking of routers and contexts also means the test verifies the mocks, not the component.

Fix or delete flaky tests rather than skipping them. Common causes are timing issues (wait for elements instead of using sleep), shared state between tests, and animations interfering with clicks; seed data explicitly and keep tests independent.