Frontend Testing Architecture

Testing strategy is an architectural decision. Too many unit tests and you test implementation details. Too many E2E tests and your suite is slow and flaky. Senior engineers design testing pyramids that maximize confidence per second of CI time.

The Testing Trophy

The modern frontend test distribution looks less like a pyramid and more like a trophy:

        ╭──────╮
        │ E2E  │         ← Few critical user journeys
        ╰──┬───╯
      ╭────┴─────╮
      │Integration│      ← Most tests live here
      ╰────┬─────╯
     ╭─────┴──────╮
     │  Component  │     ← Render + interact + assert
     ╰─────┬──────╯
        ╭───┴───╮
        │Static │        ← TypeScript + ESLint
        ╰───────╯

Static Analysis (Foundation)

TypeScript and ESLint catch entire categories of bugs before any test runs:

function calculateTotal(items: CartItem[]): number {
  return items.reduce((sum, item) => sum + item.price * item.quantity, 0);
}

Component Tests

Test components in isolation with a real DOM but mocked dependencies:

import { render, screen, fireEvent } from '@testing-library/react';
 
test('increments counter on click', () => {
  render(<Counter initial={0} />);
 
  expect(screen.getByRole('status')).toHaveTextContent('0');
  fireEvent.click(screen.getByRole('button', { name: /increment/i }));
  expect(screen.getByRole('status')).toHaveTextContent('1');
});

Key principle: Test behavior, not implementation. Query by role/text, not by test IDs or class names.

Integration Tests

Test how multiple components work together, with real state and routing:

test('search flow: type query → see results → click result', async () => {
  server.use(
    http.get('/api/search', ({ request }) => {
      const url = new URL(request.url);
      return HttpResponse.json([
        { id: 1, title: 'React Hooks' },
      ]);
    })
  );
 
  render(<App />, { wrapper: TestProviders });
 
  await userEvent.type(screen.getByRole('searchbox'), 'react');
  await screen.findByText('React Hooks');
  await userEvent.click(screen.getByText('React Hooks'));
 
  expect(screen.getByRole('heading')).toHaveTextContent('React Hooks');
});

E2E Tests

Test critical user journeys through the full stack:

test('checkout flow', async ({ page }) => {
  await page.goto('/products');
  await page.getByRole('button', { name: 'Add to cart' }).first().click();
  await page.getByRole('link', { name: 'Cart' }).click();
  await page.getByRole('button', { name: 'Checkout' }).click();
 
  await expect(page.getByText('Order confirmed')).toBeVisible();
});

What to Test at Each Level

Level	What	Example
Static	Type errors, lint rules	`CartItem` missing `price` field
Component	Render output, user interactions	Button shows loading state on click
Integration	Feature flows, state + UI	Search results update URL and display
E2E	Critical paths, cross-page flows	Sign up → Add to cart → Checkout

Testing Patterns

MSW for API Mocking

Mock Service Worker intercepts at the network level — your code uses real fetch:

import { http, HttpResponse } from 'msw';
import { setupServer } from 'msw/node';
 
const server = setupServer(
  http.get('/api/users', () => {
    return HttpResponse.json([
      { id: 1, name: 'Alex' },
      { id: 2, name: 'Sam' },
    ]);
  }),
);
 
beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

Testing Custom Hooks

import { renderHook, act } from '@testing-library/react';
 
test('useCounter increments', () => {
  const { result } = renderHook(() => useCounter(0));
 
  expect(result.current.count).toBe(0);
  act(() => result.current.increment());
  expect(result.current.count).toBe(1);
});

Snapshot Testing (Use Sparingly)

Snapshots are useful for detecting unintended changes, but they're noisy and often blindly updated:

test('renders correctly', () => {
  const { container } = render(<Badge variant="success">Active</Badge>);
  expect(container).toMatchInlineSnapshot(`
    <div>
      <span class="badge badge-success">Active</span>
    </div>
  `);
});

Prefer inline snapshots over file snapshots — they're easier to review in diffs.

Visual Regression Testing

Tools like Chromatic or Percy capture screenshots and diff against baselines:

test('button variants', async ({ page }) => {
  await page.goto('/storybook/iframe.html?id=button--all-variants');
  await expect(page).toHaveScreenshot('button-variants.png');
});

Testing Accessibility

import { axe, toHaveNoViolations } from 'jest-axe';
 
expect.extend(toHaveNoViolations);
 
test('form is accessible', async () => {
  const { container } = render(<LoginForm />);
  const results = await axe(container);
  expect(results).toHaveNoViolations();
});

Test Organization

src/
├── components/
│   ├── Button/
│   │   ├── Button.tsx
│   │   ├── Button.test.tsx      ← Component test (co-located)
│   │   └── Button.stories.tsx   ← Storybook (visual documentation)
├── hooks/
│   ├── useAuth.ts
│   └── useAuth.test.ts
├── __tests__/
│   └── integration/
│       ├── auth-flow.test.tsx   ← Integration tests
│       └── search-flow.test.tsx
└── e2e/
    ├── checkout.spec.ts         ← E2E tests (separate folder)
    └── auth.spec.ts

CI Pipeline

Static Analysis → Component Tests → Integration Tests → E2E Tests → Visual Regression
     (30s)            (1-2 min)         (2-3 min)        (3-5 min)       (2-3 min)

Fail fast: static analysis and component tests catch 80% of issues in under 2 minutes.

Interview Signal

Senior candidates demonstrate:

Testing trophy — Integration tests over unit tests, strategic E2E for critical paths
Behavior testing — Query by role/text, assert on user-visible outcomes
MSW — Network-level mocking that doesn't couple tests to implementation
Confidence per minute — Fast feedback loops, CI pipeline ordering, parallelization
Accessibility testing — Automated axe checks + manual testing strategy