Frontend Testing Strategy

1 Testing pyramid vs testing trophy

The classic pyramid says: many unit tests at the bottom, some integration in the middle, few e2e at the top. Good mental model for backends where units are pure functions. For UI, it over-indexes on unit tests that break every refactor without catching real bugs.

Kent C. Dodds proposed the testing trophy: the biggest investment is in integration tests, because they give the most ROI for UI code.

Unit vs integration — the tool isn't the boundary, the style is

Jest and Vitest are test runners — they can run both unit tests and integration tests. The type is determined by how you test, not which runner you use.

The boundary between unit and integration is isolation — not the tool, not the DOM, not whether it's a React component. A unit test mocks its dependencies so only one piece of code is under test. An integration test lets real dependencies run and verifies they work together correctly.

Unit test example — pure utility function

// formatPrice.ts
export function formatPrice(amount: number, currency: string) {
  return new Intl.NumberFormat('en-US', { style: 'currency', currency })
    .format(amount);
}

// formatPrice.test.ts — pure unit test, no DOM, no React
it('formats USD correctly', () => {
  expect(formatPrice(1234.5, 'USD')).toBe('$1,234.50');
});

it('formats THB correctly', () => {
  expect(formatPrice(500, 'THB')).toBe('฿500.00');
});

No DOM, no render, no React — just input → output. Fast, deterministic, zero setup. This is the natural home for utility logic.

Unit test example — React component in isolation

When a component has child dependencies, unit-test it by mocking those children with jest.mock(). This isolates the component under test from its subtree — you're only verifying its own logic (what it renders based on props, which callbacks it calls).

// ProductCard.tsx — depends on two child components
import { PriceTag } from './PriceTag';
import { WishlistButton } from './WishlistButton';

export function ProductCard({ name, price, onWishlist }) {
  return (
    <div>
      <h3>{name}</h3>
      <PriceTag amount={price} />
      <WishlistButton onClick={onWishlist} />
    </div>
  );
}

// ProductCard.test.tsx — unit test: children are mocked out
import { render, screen } from '@testing-library/react';

// Replace real children with stubs — only ProductCard's own logic is under test
jest.mock('./PriceTag', () => ({
  PriceTag: ({ amount }) => <span data-testid="price">{amount}</span>,
}));
jest.mock('./WishlistButton', () => ({
  WishlistButton: ({ onClick }) => <button onClick={onClick}>wish</button>,
}));

it('renders the product name', () => {
  render(<ProductCard name="Deluxe Room" price={120} onWishlist={jest.fn()} />);
  expect(screen.getByText('Deluxe Room')).toBeInTheDocument();
});

it('passes price down to PriceTag', () => {
  render(<ProductCard name="Deluxe Room" price={120} onWishlist={jest.fn()} />);
  expect(screen.getByTestId('price')).toHaveTextContent('120');
});

it('calls onWishlist when wishlist button is clicked', async () => {
  const onWishlist = jest.fn();
  render(<ProductCard name="Deluxe Room" price={120} onWishlist={onWishlist} />);
  screen.getByText('wish').click();
  expect(onWishlist).toHaveBeenCalledTimes(1);
});

PriceTag and WishlistButton are replaced with dumb stubs — their real implementations never run. The test only verifies ProductCard's own behaviour: does it render the name? Does it pass the right prop to the price stub? Does it wire up the callback? That's a unit test of a React component.

Integration test example — same ProductCard, no mocks

Same component, same runner — but now no jest.mock(). Real PriceTag and WishlistButton render, user events flow through the whole tree, and assertions are on what the user sees.

// ProductCard.test.tsx — integration test, children are NOT mocked
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { ProductCard } from './ProductCard';

// No jest.mock() — PriceTag and WishlistButton render for real

it('shows formatted price from PriceTag', () => {
  render(<ProductCard name="Deluxe Room" price={120} onWishlist={jest.fn()} />);
  // PriceTag's real formatting logic runs — we assert on the final visible output
  expect(screen.getByText('$120.00')).toBeInTheDocument();
});

it('adds to wishlist when button is clicked', async () => {
  const user = userEvent.setup();
  const onWishlist = jest.fn();
  render(<ProductCard name="Deluxe Room" price={120} onWishlist={onWishlist} />);

  await user.click(screen.getByRole('button', { name: /add to wishlist/i }));
  expect(onWishlist).toHaveBeenCalledTimes(1);
});

Same file, same runner — the only difference from the unit test above is no jest.mock(). PriceTag's real formatting runs, WishlistButton's real markup renders. If you refactor ProductCard to pass price differently, the test still passes as long as the user still sees $120.00 — it never cares about internal props or state.

2 Testing Library philosophy — test behavior, not implementation

"The more your tests resemble the way your software is used, the more confidence they can give you." — Testing Library guiding principles.

The practical consequence: never query by CSS class or internal state. Query the way a real user (or screen reader) would find an element.

Query priority

getBy* vs findBy* vs queryBy*

userEvent vs fireEvent

fireEvent.click(button) dispatches a single synthetic click event. userEvent.click(button) simulates the full event sequence a real browser fires: pointerdown → mousedown → focus → pointerup → mouseup → click. Always use userEvent — it catches bugs that fireEvent misses (handlers that listen to mousedown instead of click).

import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';

test('submits the search form', async () => {
  render(<SearchForm />);
  const user = userEvent.setup(); // v14+: setup() for better async support

  await user.type(screen.getByRole('textbox', { name: /destination/i }), 'Bangkok');
  await user.click(screen.getByRole('button', { name: /search/i }));

  // findBy* because results load async
  expect(await screen.findByText(/hotels in Bangkok/i)).toBeInTheDocument();
});

3 The tooling landscape

Why MSW beats mocking axios/fetch modules

// ❌ Module mock — brittle, only tests axios, not fetch/swr/react-query
jest.mock('axios');
(axios.get as jest.Mock).mockResolvedValue({ data: hotels });

// ✅ MSW — intercepts real network, works for any fetching library
import { http, HttpResponse } from 'msw';
import { server } from './mocks/server';

beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

// Override a handler in a specific test for an error scenario
server.use(
  http.get('/api/hotels', () => HttpResponse.error())
);

4 Flaky tests — the #1 Lead topic in testing

A flaky test is worse than no test — it teaches your team to ignore red CI and ships false confidence. Eliminating flakiness is a Lead-level discipline, not a "fix it when it bothers you" chore.

Fleet-wide flakiness management (the Lead answer)

1. Quarantine, don't delete. Mark flaky tests with a skip + open a P2 ticket. Deleting removes coverage; skipping preserves intent while stopping the noise.
2. Track a flakiness rate per suite per week. If it's above ~2%, it's a team problem, not a test problem.
3. Fix sprints. Dedicate 20% of a sprint to flakiness reduction when the rate climbs. Treat escaped flaky tests like production bugs.
4. Retry is a last resort, not a fix. Playwright/Jest retry hides root causes. One retry = OK for intermittent network. Three retries = the test is broken and you're hiding it.

5 e2e strategy at scale

e2e tests are 10–100× slower than integration tests and significantly more flaky. The Lead's goal is to keep the e2e suite small, fast, and trusted.

// playwright.config.ts — shard across 5 CI workers
export default {
  workers: process.env.CI ? 4 : undefined,
  retries: process.env.CI ? 1 : 0, // one retry in CI, zero locally
  use: {
    baseURL: 'http://localhost:3000',
  },
  // package.json CI: playwright test --shard=1/5, 2/5, 3/5 …
};

6 Visual regression testing

Visual regression tests capture a baseline screenshot of a component or page, then compare it against every subsequent PR. Pixel diffs surface unintended CSS changes — color, spacing, typography, layout — before they reach production.

Tooling

Storybook + play() — document AND test simultaneously

A Storybook play() function runs Testing Library interactions inside a story. Chromatic captures the visual output of each interaction state. One story gives you: documentation, interactive demo, visual regression baseline, and an interaction test — all from the same source.

// HotelCard.stories.tsx
export const WithFavourite: Story = {
  play: async ({ canvasElement }) => {
    const canvas = within(canvasElement);
    await userEvent.click(canvas.getByRole('button', { name: /save hotel/i }));
    // Chromatic screenshots the filled-heart state — visual regression included
  },
};

7 Coverage — signal not target

100% coverage is a vanity metric. You can cover every line with tests that make no meaningful assertions:

test('renders without crashing', () => {
  render(<PaymentForm />); // 100% line coverage, zero behaviour tested
});

Practical floor: Set a coverage gate at a low floor (60–70%) to catch cases where a whole feature ships with zero tests. Investigate drops, don't chase the ceiling. Coverage of critical payment and auth paths should be high by intent — not because the gate forced it.

8 Testing in CI/CD — gating and culture

The CI signal hierarchy

Raising testing culture from zero

Mandating tests creates resentment. Making tests easy creates adoption. The Lead playbook:

1. Pair on the first test per team. Sit with an engineer and write one test together for their feature. Remove the blank-page problem.
2. Shared test infra. Create a test-utils package with pre-configured render wrappers (providers, MSW server, custom queries). Writing a test should start with one import, not 30 lines of setup.
3. Track escaped defects. Every post-mortem asks "was there a test that could have caught this?" Over a quarter, patterns emerge — write tests for those patterns.
4. Celebrate, don't mandate. Recognise PRs that add meaningful test coverage. Review tests as carefully as code in PR review.
5. Set a floor, not a ceiling. Coverage gate at a low floor prevents zero-coverage features. Chasing 100% is the lead's job to prevent.

9Check yourself — scenario quiz