A Practical Frontend Testing Strategy That Does Not Waste Your Time

The testing pyramid (many unit tests, some integration tests, few end-to-end tests) was designed for backend services with clear inputs and outputs. It does not map well to frontend applications where: the boundary between units is blurry, integration between components is where bugs actually live, and user experience is the thing you are actually testing.

Here is the frontend testing strategy I use — pragmatic, focused on confidence, and designed to catch real bugs rather than satisfy coverage metrics.

The Frontend Testing Trophy

Instead of the testing pyramid, I follow the testing trophy (coined by Kent C. Dodds): a small base of static analysis (TypeScript, ESLint), a large middle of integration tests (components rendered together), a smaller section of unit tests (pure logic), and a small top of end-to-end tests (critical user flows).

The key insight: integration tests give the highest confidence-per-effort for frontend code. Testing components in isolation misses the bugs that occur when components interact. Testing full user flows end-to-end is expensive and slow. Integration tests hit the sweet spot.

Layer 1: Static Analysis (Free Confidence)

TypeScript and ESLint catch bugs before you write a single test. They are always running, require no maintenance, and catch: type errors (passing string where number expected), undefined variable access, unused imports and variables, accessibility issues (eslint-plugin-jsx-a11y), and common React mistakes (exhaustive deps, invalid hook calls).

This is free confidence. Every project should have strict TypeScript and comprehensive ESLint rules. They catch 30% of bugs that would otherwise require tests.

Layer 2: Integration Tests (Highest ROI)

Integration tests render multiple components together and test user-facing behavior. Not implementation details (state values, method calls), but outcomes (what the user sees and can do).

Tool: Vitest + React Testing Library. This combination: renders components in a simulated DOM, provides user-centric query methods (getByRole, getByText — not getByTestId), and runs fast (milliseconds per test).

What to test at this layer: component rendering with various props and states, user interactions (clicking, typing, selecting) and their results, conditional rendering (show/hide based on state), form submission and validation feedback, and data display from props or context.

Example: test that a ToolCard component renders the tool name, shows the rating stars, and navigates to the tool page when clicked. Test with different props: free tool vs paid tool, rated vs unrated, bookmarked vs not bookmarked.

What NOT to test: implementation details (which state variable holds the value), internal method calls, render counts, and exact CSS classes or styles.

Layer 3: Unit Tests (Pure Logic Only)

Unit tests for frontend code are valuable only for pure logic — functions with inputs and outputs that do not depend on React, the DOM, or external state.

Candidates for unit tests: utility functions (formatting, parsing, validation), data transformation functions (mapping API responses to component props), calculation logic (pricing, scoring, pagination math), and custom hooks that encapsulate complex logic.

NOT candidates for unit tests: components (use integration tests instead), hooks that are just wrappers around useState, and functions that primarily call external services.

The rule: if a function is pure (same inputs always produce same outputs, no side effects), unit test it. If it interacts with React or the DOM, integration test it.

Layer 4: End-to-End Tests (Critical Paths Only)

E2E tests (Playwright) run in a real browser against your actual application. They catch: deployment configuration issues, API integration failures, authentication flows, cross-page navigation, and client-server communication problems.

But they are slow (seconds per test vs milliseconds for unit/integration), flaky (network issues, timing, race conditions), and expensive to maintain (break when UI changes, even if behavior is correct).

Strategy: test only critical user paths that MUST work: user authentication (signup, login, logout), primary product flow (search for a tool, view tool page, bookmark it), payment flow (if applicable), and admin critical actions.

That is 5-10 E2E tests, not hundreds. They run in CI on every PR and provide confidence that the deployed application actually works end-to-end. Everything else is covered by faster integration tests.

What to Skip Testing

Testing that adds maintenance burden without confidence:

Snapshot tests: they break on every visual change, produce noise in PRs, and teach you nothing when they fail. The failure message is "snapshots do not match" — you have to visually inspect to decide if the change is intentional.

Testing third-party library behavior: do not test that React Router navigates correctly or that Prisma returns data. Test YOUR code that USES these libraries.

Testing CSS/styling: visual regression testing tools (Chromatic, Percy) handle this better than assertions. If styling matters for your tests, consider visual regression testing as a separate concern.

100% coverage: coverage metrics measure quantity, not quality. 80% coverage with thoughtful tests is better than 100% coverage with meaningless assertions.

The Testing Workflow

When building a new feature:

Write the component/feature without tests (get it working first).

Add integration tests for the key behaviors (what the user sees and does).

Add unit tests for any pure logic extracted into utility functions.

If the feature is a critical user path, add one E2E test.

When fixing a bug:

Write a test that reproduces the bug (fails with the current code).

Fix the bug.

Verify the test passes.

The test prevents regression forever.

Testing Component Libraries

For shared component libraries (our packages/tools package): test more thoroughly than application components because: many consumers depend on the behavior, changes affect multiple pages, and the components are expected to be stable.

For each shared component: test all prop combinations, test keyboard interaction (accessibility), test responsive behavior (if applicable), and test error states and edge cases.

Mocking Strategy

Mock as little as possible. The more you mock, the less your test resembles reality. Tests with extensive mocking can pass while the real application fails.

What to mock: network requests (use MSW — Mock Service Worker — to intercept HTTP requests and return test data), time-dependent functions (fake timers for debouncing, animations), and external services (payment processors, auth providers in non-E2E tests).

What NOT to mock: other components (render them for real), browser APIs (use them in jsdom or happy-dom), and state management (let it work naturally).

CI Integration

Tests run on every PR: static analysis (TypeScript + ESLint) runs first (fastest, catches obvious issues), unit and integration tests run second (fast, high confidence), E2E tests run last (slowest, highest fidelity).

Fail the PR if any layer fails. Do not merge code with failing tests. This sounds obvious but requires discipline — "I will fix the test later" never happens.

The Pragmatic Bottom Line

A frontend testing strategy should: catch real bugs before users encounter them, run fast enough that developers do not skip them, be maintainable (tests should not break with every refactor), and provide confidence to deploy without manual testing.

The strategy that achieves this: TypeScript everywhere, integration tests for component behavior, unit tests for pure logic, E2E tests for critical paths, and nothing else. No snapshot tests, no 100% coverage mandates, no testing of library internals. Focus on confidence, not metrics.