React testing — unit, integration, E2E (draft)
#frontend#guide
Draft — how I usually layer tests in React SPAs, tied back to Testing strategy. I’ll add examples and tooling versions when I merge in presentation notes.
Split-out placeholders (for future Reveal deck imports): Frontend testing, React unit testing, React integration testing. Backend counterpart: NestJS integration testing.
Unit
- Runners: Jest or Vitest (Vite-native, Jest-compatible API, very fast in watch mode).
- Component tests: React Testing Library — interact like a user, query by role/label, avoid testing private structure.
- Scope: pure logic, hooks with controlled providers, small components with minimal mocking.
Integration (browser-shaped)
- Tools: Playwright or Cypress — real browser, real router, often mocked HTTP (MSW, intercept routes, or stub backends) so cases stay repeatable.
- Narrow integration testing: a thin slice of the stack is real (e.g. UI + router + client state); dependencies are stubbed—one module, one API boundary, or a fake server with fixed payloads. Fast feedback, still catches wiring bugs.
- Broad integration testing: more of the stack is real—multiple services, real auth cookie flow, or a containerized dependency. Higher confidence, slower, more setup. I use this after narrow tests pass, not instead of them.
E2E
- Full path through deployed or preview environments against real backends (or prod-like sandboxes). Few tests, high value: critical journeys only. Pairs naturally with review apps and CI ordering—see GitLab CI for a frontend.
Non-functional angle
Performance, a11y, visual regression, and security scans sit beside this pyramid—Non-functional testing.