Frontend Testing Strategy: Unit, Integration, and End-to-End

By /
⏱ 3 min read

Frontend testing has matured significantly — Jest is sometimes replaced by Vitest, Cypress and Playwright dominate E2E, and React Testing Library is the de facto unit testing approach. The interview tests whether you understand the layers, the tradeoffs, and how to balance test coverage with maintenance burden.

The testing pyramid (modern interpretation)

Classic: many unit tests, fewer integration tests, even fewer E2E tests.

Modern frontend reality: more like a “testing trophy” (Kent C. Dodds) — heavier on integration tests, lighter on isolated unit tests, with a few high-value E2E tests at the top.

Unit tests

  • Test pure functions and utilities
  • Test custom hooks with @testing-library/react-hooks
  • Avoid testing React components in isolation with shallow rendering — produces fragile tests with low signal

Tools: Vitest (replacing Jest), built-in React Testing Library.

Integration tests

Render real components, fire user events, assert on what the user would see. The bulk of valuable frontend tests.

Example with React Testing Library:

test('submits form and shows success', async () => {
  render(<LoginForm />);
  await user.type(screen.getByLabelText(/email/i), 'a@b.com');
  await user.type(screen.getByLabelText(/password/i), 'pass');
  await user.click(screen.getByRole('button', { name: /sign in/i }));
  expect(await screen.findByText(/welcome/i)).toBeInTheDocument();
});

Mock the API at the boundary (with MSW — Mock Service Worker) rather than mocking individual fetch calls.

End-to-end tests

Real browser, real navigation, often real backend.

Tools: Playwright (mature, fast, multi-browser), Cypress (popular, great DX). Both are good — Playwright wins on speed and parallelization; Cypress wins on debugging UX.

What to test in E2E:

  • Critical user journeys (signup, checkout, key feature)
  • Cross-page workflows that integration tests cannot cover
  • Browser-specific behavior

What not to test in E2E:

  • Edge cases that integration tests cover
  • Forms with many validation rules — integration faster
  • Pure UI variations — visual regression is better

Visual regression

Tools: Chromatic, Percy, Playwright’s screenshot mode.

Best for: catching unexpected UI changes (a refactor changes button styling, a deployment breaks a layout).

Tradeoffs: flaky on dynamic content; expensive to maintain. Use for design-system components and high-stakes pages.

Accessibility tests

axe-core in your test suite. Catches the easy bugs (missing labels, contrast issues, ARIA mistakes). Does not replace manual testing with screen readers.

Test against the right boundaries

Mock at the network boundary (MSW), not at the function boundary. Why:

  • Tests behave like real usage — same code paths exercised
  • Refactoring internal functions does not break tests
  • Mock contracts are stable (HTTP requests, not internal APIs)

What to avoid

  • Snapshot testing for full component output — fragile, low signal
  • Testing implementation details (state, internal functions)
  • 100% coverage as a goal — diminishing returns above 70–80%
  • Mocking everything — at some point you are testing your mocks

Performance and reliability

  • Run unit + integration tests on every commit
  • Run E2E on PR and pre-deploy
  • Run visual regression weekly or on design-impacting PRs
  • Parallelize aggressively — modern test runners support this natively

Test environment

  • Use jsdom for unit/integration (fast, no browser overhead)
  • Use real browsers for E2E (Playwright launches Chromium, Firefox, WebKit)
  • Run E2E in CI in a stable, deterministic environment (Docker containers)

Frequently Asked Questions

Should I use Vitest or Jest in 2026?

Vitest for new projects (faster, ESM-native, less config). Jest for existing large codebases (mature, ecosystem). Both are good.

How do I handle async testing?

findBy* queries from React Testing Library auto-wait. Use waitFor for non-DOM async assertions. Avoid setTimeout/sleep in tests.

What is the right test coverage target?

70–85% for most projects. Above that, ROI drops. Focus on critical paths over coverage numbers.

Scroll to Top