Week 14: Unit Testing React Apps

1. Vitest Setup

Vitest is a test runner built for Vite projects — same configuration, same fast dev-server-style re-runs, and a Jest-compatible API if you've used Jest before.

npm install -D vitest @testing-library/react @testing-library/user-event @testing-library/jest-dom jsdom

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()],
  test: {
    environment: 'jsdom', // simulates a browser DOM in Node
    setupFiles: './src/test-setup.ts',
    globals: true,
  },
});

import '@testing-library/jest-dom'; // adds matchers like .toBeInTheDocument()

import { describe, it, expect } from 'vitest';

function sum(a: number, b: number) {
  return a + b;
}

describe('sum', () => {
  it('adds two numbers', () => {
    expect(sum(2, 3)).toBe(5);
  });
});

jsdom is what makes browser-like testing possible in Node at all — it simulates a DOM well enough that React can render into it and your test can query the result, without ever opening a real browser.

2. React Testing Library's Philosophy

React Testing Library (RTL) is built around one guiding principle, printed on its own homepage: "the more your tests resemble the way your software is used, the more confidence they can give you." In practice, that means testing what a user sees and does — visible text, buttons, form fields — rather than a component's internal state or implementation details.

// Fragile: breaks if you rename the internal state variable,
// even if the component's actual behavior is unchanged.
expect(wrapper.state('isOpen')).toBe(true);
expect(wrapper.find('.internal-class-name')).toHaveLength(1);

// Resilient: this passes as long as the user-visible outcome is correct,
// regardless of how the component achieves it internally.
expect(screen.getByRole('dialog')).toBeInTheDocument();
expect(screen.getByText('Settings saved')).toBeInTheDocument();

This philosophy is why RTL deliberately has no API for reaching into a component's props or internal state — it's a constraint, not a missing feature. A test written this way keeps passing through a component being refactored from useReducer to useState, or from a class to a function, because none of that changes what the user actually sees or can click.

3. Queries & User Events

RTL's queries (getByRole, getByLabelText, getByText...) find elements the way an assistive technology or a real user would identify them — which is also why writing tests this way tends to surface accessibility problems (Week 21) for free.

import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { describe, it, expect } from 'vitest';
import Counter from './Counter';

describe('Counter', () => {
  it('increments when the button is clicked', async () => {
    const user = userEvent.setup();
    render(<Counter />);

    expect(screen.getByText('Count: 0')).toBeInTheDocument();

    const button = screen.getByRole('button', { name: /increment/i });
    await user.click(button);

    expect(screen.getByText('Count: 1')).toBeInTheDocument();
  });
});

getByRole('button', {'{ name: /increment/i }'}) finds the button the same way a screen reader would announce it — by its accessible role and name — not by a CSS class or test-specific attribute. @testing-library/user-event (not the lower-level fireEvent) simulates a real click as a full sequence of browser events (pointer down, focus, pointer up, click), catching bugs a simplified synthetic event would miss.

it('shows a validation error for an invalid email', async () => {
  const user = userEvent.setup();
  render(<SignupForm />);

  await user.type(screen.getByLabelText('Email'), 'not-an-email');
  await user.click(screen.getByRole('button', { name: /sign up/i }));

  expect(await screen.findByText(/enter a valid email/i)).toBeInTheDocument();
});

findByText (rather than getByText) returns a promise and retries until the element appears or a timeout elapses — necessary here because React Hook Form's validation (Week 5) runs asynchronously after submission, so the error message isn't in the DOM the instant click resolves.

4. Mocking Network Requests with MSW

A component test shouldn't depend on a real backend being available and returning consistent data. Mock Service Worker (MSW) intercepts actual fetch calls at the network level and returns data you control — your component code doesn't know it's being tested at all.

npm install -D msw

import { http, HttpResponse } from 'msw';

export const handlers = [
  http.get('/api/users/:id', ({ params }) => {
    return HttpResponse.json({ id: Number(params.id), name: 'Ada Lovelace' });
  }),
];

import '@testing-library/jest-dom';
import { setupServer } from 'msw/node';
import { handlers } from './mocks/handlers';

const server = setupServer(...handlers);

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

it('shows the fetched user name', async () => {
  render(<UserProfile userId={5} />);
  expect(await screen.findByText('Ada Lovelace')).toBeInTheDocument();
});

This is a meaningfully better approach than mocking your fetchUser function directly — UserProfile runs its actual, real fetch call, and only the network layer underneath it is faked. The test verifies your real request logic and real response handling, not just that a mocked function was called with the right arguments.

5. Testing Custom Hooks & Coverage

A custom hook (Week 4) is just a function, but it can't be called directly in a test the way a plain function can — it uses useState/useEffect internally, which only work inside React's render cycle. Testing Library's renderHook solves this by mounting the hook inside a minimal invisible component for you.

import { useState, useCallback } from 'react';

export function useCounter(initial = 0) {
  const [count, setCount] = useState(initial);
  const increment = useCallback(() => setCount((c) => c + 1), []);
  const reset = useCallback(() => setCount(initial), [initial]);
  return { count, increment, reset };
}

import { renderHook, act } from '@testing-library/react';
import { describe, it, expect } from 'vitest';
import { useCounter } from './useCounter';

describe('useCounter', () => {
  it('increments and resets', () => {
    const { result } = renderHook(() => useCounter(5));

    expect(result.current.count).toBe(5);

    act(() => result.current.increment());
    expect(result.current.count).toBe(6);

    act(() => result.current.reset());
    expect(result.current.count).toBe(5);
  });
});

act() wraps any code that triggers a state update outside of an event RTL already wraps for you (like calling result.current.increment() directly) — it flushes React's pending updates before the next assertion runs, the same guarantee userEvent gives you for free in component tests.

npx vitest run --coverage

A coverage percentage tells you which lines executed during your test run — it says nothing about whether the right assertions ran against them. 100% coverage with weak assertions (expect(result).toBeTruthy() everywhere) is worse than 70% coverage of your app's actual critical paths — signup, checkout, anything money or auth touches — tested thoroughly.

6. Hands-on Exercise

7. Knowledge Check

Four quick questions. Expand each to check your answer.