Testing
Frontend testing toolchain — strategy, unit tests, component tests, end-to-end, and mobile testing
Frontend Testing
The frontend has its own testing problems: user interactions are messy, the DOM (or widget tree) is stateful, asynchronous behavior is everywhere, and "it looks right" is not assertable. The toolchain that solves these is different from backend testing — but the strategy is the same.
For the language-agnostic foundations (test pyramid, FIRST properties, test doubles, what to test where), see Testing Strategy under code-craft. This section covers the frontend-specific toolchain and patterns.
Topics
Strategy
Test pyramid applied to frontend; what to test at which level on web and mobile
Unit Tests
Vitest / Jest, pure logic, hooks, utilities, mocking patterns
Component Tests
React Testing Library, Flutter widget test, RN Testing Library — testing user-visible behavior
End-to-End
Playwright, Cypress, Detox, Maestro — driving the real app
Mobile Testing
Flutter integration tests, Detox/Maestro on iOS+Android, device matrices, golden tests
Frontend Testing Stack at a Glance
| Layer | Web (React) | Flutter | React Native |
|---|---|---|---|
| Unit | Vitest / Jest | flutter test | Jest |
| Component | React Testing Library | flutter test (widget test) | RN Testing Library |
| Integration | RTL + MSW | integration_test package | RN Testing Library + MSW |
| E2E | Playwright / Cypress | integration_test on device | Detox / Maestro |
| Visual / Golden | Chromatic / Percy | matchesGoldenFile | react-native-screenshot or third-party |
Cross-Cutting Concerns
A few problems show up at every layer of frontend testing:
- Async everywhere. Network, animations, timers, gesture recognizers. The runner must understand "wait for this to settle."
- User-centric assertions. Tests should describe what a user sees, not what the framework rendered internally.
- Mocking network at the right level. Mock the transport (MSW,
http.Clientoverrides, Detox network stubs), not the data-access layer — otherwise the wiring you most want to test is bypassed. - Determinism on real devices. Animations, fonts loading, network latency — all sources of flakiness in mobile and E2E tests.
- The CI matrix. Web + iOS + Android multiplies the surface; the suite has to be designed for parallel execution and partial-failure tolerance.
Each subsection covers one of these in its native context.
Starting Points
- Adding tests to a legacy frontend? Start with component tests for the highest-value screens; defer unit tests until the design is more testable. See Component Tests.
- Stabilizing a flaky suite? Most flakes are async-related. See the diagnostic checklist in Strategy.
- Adding E2E to a mobile app? Start with the single most important journey end-to-end; resist the pull to test everything. See Mobile Testing.
- Setting up CI? Split fast tests (unit + component, run on every commit) from slow tests (E2E, run on merge). See CI/CD.