A Brief Note on Frontend Testing
We can divide frontend testing in SaaS applications in four pillars: Static code analysis (ESLint, TypeScript), Unit tests, Component tests, E2E tests. Each of them serves a different purpose. To keep frontend testing efficient, use each layer where it delivers the most value rather than trying to max out every level of the classic testing pyramid.
The different pillars / levels
Static code analysis
Cheapest form of testing. Finds problems like unused variables, writes to const, etc. TypeScript additionally warns us about possible typing errors.
Unit tests
Test logical code snippets in complete isolation to ensure correct implementation. Do not unit-test everything, but things that are not covered (sufficiently) by component tests. These would be
- Important / complicated parts of logic (anywhere, also within components)
- Stores and their communication to the backend (store.saveUser is called → in GraphQL request the username is contained)
- Composables
Component tests
The main testing approach for the frontend. Tests each component in isolation from the upper hierarchy. Renders children out and evaluates the integration between children and component. Asserts correct UI behaviour by interacting with it, event emission and general component functionality. Checks if it calls the correct store functions to save data. Checks
- Emitted events
- Usage of props
- Interactions and subsequent interface changes (for example required input field not filled on submit button click → error message)
- Store interactions (stores fully mocked with stubs to check method calls and with test data to check correct rendering)
E2E
Slowest, but most exhaustive and significative form of testing an application. Simulates a real user using the entire application in conjunction. Should test core functionalities and most important user journeys.
- Main user journeys
- Asserts correct functioning of entire application
Closing
If this note has one takeaway, it is choose tests by risk, not by habit. Put complex logic under unit tests, validate behavior through component tests, and reserve E2E for critical journeys. That way, the suite supports development instead of slowing it down.
A great resource were the ideas on efficient frontend testing by Kent C. Dodds: https://kentcdodds.com/blog/write-tests
