Testing React

"The more your tests resemble the way your software is used, the more confidence they can give you." — Kent C. Dodds

You have spent seven parts of this Volume learning how React works — how it renders, holds state, runs effects, and recovers from errors. This part is about proving it still works tomorrow, after the next refactor, the next feature, the next tired Friday commit. That proof is what tests are. But there is a right way and a wrong way to write them, and the difference is the single most important idea in this chapter: a good test knows what the user does, not how the component is built. Interviewers love this topic precisely because it separates people who can write React from people who can ship it and sleep at night — and because the wrong instinct here is so common that saying the right thing out loud is a strong signal.

Core Concepts

Start with the philosophy, because every API decision flows from it. Test behaviour, not implementation. A user of your app never knows you kept the count in useState versus useReducer, never sees a prop named onToggle, never reads a CSS class. They see text, they click buttons, they read what changed. So that is what a test should assert on too. Rename a state variable, swap a useState for a store, split one component into three — if the visible behaviour is unchanged, a behaviour-focused test stays green. That is the whole game: tests that break only when the user's experience breaks. A test that asserts wrapper.state().count === 1 breaks on a refactor that changed nothing the user can perceive. That test isn't protecting you; it's taxing you.

The toolkit

Four pieces, each with one job:

RTL deliberately gives you no way to reach a component's state or props. That constraint is the feature — it makes writing a bad test harder than writing a good one.

The core RTL loop: render, act, assert

Here is the component under test, live below so you can play with it. Its test sits in the snippet right after — read them together.

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

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

  // Query the way a user would: by the button's accessible role + name.
  expect(screen.getByText('Count: 0')).toBeInTheDocument();

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

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

Three moves, always in this order. Render the component into jsdom. Act — drive the interaction with user-event (note await: user-event v14 is async because real events are). Assert with expect(...) and a matcher like toBeInTheDocument() (that matcher comes from @testing-library/jest-dom). Notice what the test never mentions: no useState, no setCount, no internal count variable. It clicks a button and checks the screen — exactly what a user does.

Queries: prefer the ones a user (and a screen reader) can use

RTL offers many query methods, and their priority order is not arbitrary — it mirrors how accessible your UI is. Reach for them top-down:

The lesson hides in the ranking: if you can't query by role or label, that's often a real accessibility bug your test just surfaced. Reaching for getByTestId too early hides that bug instead of fixing it.

Async: things that appear after a tick

Real components fetch data. You can't assert on a result that hasn't arrived — so RTL gives you findBy* (a getBy that retries until the element shows up or times out) and waitFor (retry an arbitrary assertion). And you don't hit the network in a unit test; you mock it with vi.mock (Vitest) so the test is fast and deterministic.

import { render, screen } from '@testing-library/react';
import { vi, expect, test } from 'vitest';
import { UserCard } from './UserCard';

// Replace the real module with a fake for this test file.
vi.mock('./api', () => ({
  fetchUser: vi.fn().mockResolvedValue({ name: 'Ada Lovelace' }),
}));

test('shows the user name after it loads', async () => {
  render(<UserCard id="42" />);

  // Present immediately while the promise is pending:
  expect(screen.getByText(/loading/i)).toBeInTheDocument();

  // findBy retries until the awaited element appears (or times out ~1s):
  expect(await screen.findByText('Ada Lovelace')).toBeInTheDocument();
});

Testing custom hooks, and what lives above unit tests

Most logic should be tested through the component that uses it. But a genuinely reusable hook can be tested directly with renderHook, which mounts it inside a throwaway component and hands you its return value via result.current (wrap updates in act):

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

test('useCounter increments', () => {
  const { result } = renderHook(() => useCounter());
  act(() => result.current.increment());
  expect(result.current.count).toBe(1);
});

RTL tests run in jsdom — fast, but not a real browser. For "does the whole flow work in Chrome, across pages, with real navigation and network," you climb to end-to-end tests with Playwright or Cypress, which drive an actual browser. The rule of thumb (the "testing trophy"): lots of fast integration tests in RTL, a thin layer of E2E for critical journeys like sign-up and checkout, few pure-unit tests.

Common Mistakes

• Asserting on state or props. expect(component.state.count).toBe(1) couples the test to the implementation. Assert on rendered output instead — it's what the user sees and what should actually be protected.
• Overusing data-testid. Reaching for getByTestId first skips the accessible query it should have used, and quietly hides an accessibility gap. Test IDs are the escape hatch, not the front door.
• Forgetting to await interactions. user.click(...) and findBy* return promises. Drop the await and assertions run against a half-updated DOM — the classic flaky test.
• Using getBy to check something is absent. getBy throws when it finds nothing, failing the test before your assertion runs. Use queryBy with .not.toBeInTheDocument() for absence.
• Testing third-party libraries. Don't write tests that verify React Router navigates or that a date library formats correctly — that's their job, already done. Test your code's use of them.
• Chasing 100% coverage. Coverage counts lines executed, not behaviours verified. A suite can be 100% green, 100% covered, and still assert nothing meaningful. Test the behaviours that matter, not every line.

Interview Corner

Chapter Summary

• The guiding principle: test behaviour, not implementation — assert on what the user sees and does, never on internal state, props, or structure. Such tests break only when the experience breaks.
• The toolkit: Vitest/Jest (runner) + React Testing Library (render + queries) + jsdom (fake DOM) + user-event (realistic interaction).
• The loop is always render → act → assert: render(), drive with await userEvent..., check with expect(...).toBeInTheDocument().
• Query priority — role > label > text > testid — mirrors accessibility; needing getByTestId is often a sign of a real a11y gap.
• Async: findBy* retries until an element appears, waitFor retries an assertion, and vi.mock fakes the network so tests are fast and deterministic. Always await interactions and async queries.
• Test hooks directly with renderHook only when they're truly reusable; climb to Playwright/Cypress E2E for a thin layer of critical, real-browser journeys.
• Don't test third-party libraries, don't chase 100% coverage, and never assert on internals.

Editorial reflection — the deepest lesson of testing isn't a library; it's a stance. Every time you choose to assert on what the user sees rather than how you built it, you are quietly deciding that your code exists to serve people, not to preserve its own structure. That stance outlives Vitest, outlived Enzyme, and will outlive whatever replaces RTL — because it is really just empathy, written down in a form the machine can check. Learn the API, yes. But carry the stance; it is the part that makes you senior.