Frontend test suites fail in two opposite ways: none at all, or hundreds of brittle tests asserting internal details that break on every refactor while catching no real bugs. The escape from both is one principle: test what the user and the consuming code can observe, and let everything else stay free to change.
A pyramid that works for Vue
- Unit tests for pure logic, composables, utilities, store actions, where Vitest runs hundreds per second.
- Component tests with Testing Library: render with props, interact the way a user does, assert on what appears. Queries by role and label double as an accessibility audit.
- End-to-end tests with Playwright or Cypress for the handful of flows whose breakage is an incident: signup, login, checkout, the core loop.
What not to write
Skip tests that assert a component's internal state, count renders, or snapshot entire DOM trees, since they verify implementation, not behavior, and they train the team to ignore red. Skip testing the framework: v-if works, Vue proved it. And skip mocking so much that the test passes while the integration it represents is broken; mock at the network boundary, not between your own modules.
Make the suite a tool, not a tax
Fast feedback is the entire game: Vitest watching changed files during development, the full suite in CI on every pull request, flakes fixed or deleted the week they appear. Write a regression test with every bug fix, because bugs recur in families. Coverage numbers are a smell test, not a goal; the honest metric is whether a red suite makes you stop and whether a green one lets you deploy without ceremony.