Testing React Components

In Building Tables and Data Grids I covered sorting, filtering, pagination, and the state machine that keeps a data grid predictable under real usage. That state machine is exactly the kind of code that breaks silently when someone "just tweaks" a filter reducer six months from now. Tests are what catch that before a customer does.

This post is part of the React & Next.js Complete Guide series. It covers how to test React components in a way that actually pays for itself: what to test, what to skip, and how to structure tests so they survive refactors instead of fighting them.

I am going to be opinionated here. Most teams either test nothing meaningful or over-test implementation details that make every refactor a chore. Both failure modes come from the same root cause: not having a clear model of what a test is for.

What a component test should actually verify

A component test earns its keep when it verifies behavior a user or another developer depends on. That means: what renders given certain props or state, what happens when someone clicks, types, or submits, and what the component calls out to (an API, a callback prop, a router).

It does not mean asserting that a specific useState call exists, or that an internal helper function ran exactly once. Those are implementation details. If you assert on them, every refactor that changes the internals without changing the behavior breaks your test suite for no reason, and your team starts ignoring red tests because "it's probably just the test."

This is the core idea behind React Testing Library, and it is worth internalizing even if you use a different tool: test the thing as a user would interact with it, not as the compiler sees it.

// UserInviteForm.tsx
import { useState } from "react";

interface UserInviteFormProps {
  onInvite: (email: string) => Promise<void>;
}

export function UserInviteForm({ onInvite }: UserInviteFormProps) {
  const [email, setEmail] = useState("");
  const [status, setStatus] = useState<"idle" | "submitting" | "error">("idle");
  const [error, setError] = useState<string | null>(null);

  async function handleSubmit(event: React.FormEvent) {
    event.preventDefault();
    if (!email.includes("@")) {
      setStatus("error");
      setError("Enter a valid email address.");
      return;
    }
    setStatus("submitting");
    try {
      await onInvite(email);
      setEmail("");
      setStatus("idle");
      setError(null);
    } catch {
      setStatus("error");
      setError("Could not send the invite. Try again.");
    }
  }

  return (
    <form onSubmit={handleSubmit}>
      <label htmlFor="invite-email">Email</label>
      <input
        id="invite-email"
        type="email"
        value={email}
        onChange={(event) => setEmail(event.target.value)}
      />
      <button type="submit" disabled={status === "submitting"}>
        Send invite
      </button>
      {error ? <p role="alert">{error}</p> : null}
    </form>
  );
}

A useful test for this component checks what happens when a user types an invalid email and submits, what happens when the API call fails, and what happens on success. It does not need to know that status is a string union or that setError exists.

// UserInviteForm.test.tsx
import { render, screen } from "@testing-library/react";
import userEvent from "@testing-library/user-event";
import { UserInviteForm } from "./UserInviteForm";

describe("UserInviteForm", () => {
  it("shows a validation error for an invalid email", async () => {
    const user = userEvent.setup();
    const onInvite = jest.fn();
    render(<UserInviteForm onInvite={onInvite} />);

    await user.type(screen.getByLabelText("Email"), "not-an-email");
    await user.click(screen.getByRole("button", { name: "Send invite" }));

    expect(screen.getByRole("alert")).toHaveTextContent("valid email");
    expect(onInvite).not.toHaveBeenCalled();
  });

  it("clears the input after a successful invite", async () => {
    const user = userEvent.setup();
    const onInvite = jest.fn().mockResolvedValue(undefined);
    render(<UserInviteForm onInvite={onInvite} />);

    await user.type(screen.getByLabelText("Email"), "teammate@example.com");
    await user.click(screen.getByRole("button", { name: "Send invite" }));

    expect(onInvite).toHaveBeenCalledWith("teammate@example.com");
    expect(await screen.findByLabelText("Email")).toHaveValue("");
  });

  it("shows an error message when the invite call rejects", async () => {
    const user = userEvent.setup();
    const onInvite = jest.fn().mockRejectedValue(new Error("network"));
    render(<UserInviteForm onInvite={onInvite} />);

    await user.type(screen.getByLabelText("Email"), "teammate@example.com");
    await user.click(screen.getByRole("button", { name: "Send invite" }));

    expect(await screen.findByRole("alert")).toHaveTextContent("Could not send");
  });
});

Notice these tests query by label and role, the same way a screen reader or a person scanning the page would find these elements. This pays off twice: it keeps the tests resilient to markup changes, and as a side effect, it forces you to keep your components accessible.

Choosing what deserves a test in the first place

Not every component needs its own test file. A presentational component that maps props straight to JSX with no branching logic is low risk. If it renders wrong, a visual regression or a five-second glance at Storybook catches it. Writing a unit test for it mostly adds maintenance cost with little payoff.

The components worth testing directly are the ones with actual decision points: conditional rendering based on state, form validation, derived values, anything with a loading or error path, and anything that calls out to an API or a store. In the data grid from the previous article, the filter and sort logic is exactly this kind of code, and it is worth testing in isolation from the rendering, ideally as a pure reducer function you can call with plain objects.

// gridReducer.test.ts
import { gridReducer, initialGridState } from "./gridReducer";

it("resets the page to 1 when a filter changes", () => {
  const stateOnPageThree = { ...initialGridState, page: 3 };
  const next = gridReducer(stateOnPageThree, {
    type: "SET_FILTER",
    key: "status",
    value: "active",
  });

  expect(next.page).toBe(1);
  expect(next.filters.status).toBe("active");
});

Testing the reducer directly, with no rendering involved, is faster to run and easier to reason about than driving the same behavior through simulated clicks. Save the rendering tests for the parts where rendering itself is the thing under test.

Mocking data fetching without lying to yourself

Most non-trivial components fetch data, and how you mock that fetch determines whether your tests catch real bugs or just confirm your mocks work. Two approaches show up constantly:

Mocking the fetch client directly (jest.mock("./api")) is fast to write but couples the test to your implementation. If you swap fetch for a different HTTP client, every test that mocks the module breaks even though the component's behavior did not change.

Mocking at the network layer with a tool like MSW (Mock Service Worker) intercepts the actual HTTP request, so the component code path, including your real fetch call and error handling, runs unmodified. This is closer to an integration test and catches more real bugs, at the cost of a bit more setup.

// mocks/handlers.ts
import { http, HttpResponse } from "msw";

export const handlers = [
  http.get("/api/users/:id/invoices", ({ params }) => {
    return HttpResponse.json([
      { id: "inv_1", amount: 4900, status: "paid" },
      { id: "inv_2", amount: 4900, status: "open" },
    ]);
  }),
];

For a SaaS codebase with real API surface area, I lean toward MSW for anything that touches data fetching, and reserve module mocks for things that are genuinely infrastructure, like a logging client or an analytics SDK you never want to fire in tests.

Snapshot tests: use sparingly, not by default

Snapshot testing feels productive because it is nearly free to add: render a component, capture the output, done. The problem is that snapshots do not encode intent. When a snapshot fails, the fix is almost always --updateSnapshot, not a careful look at whether the change is correct. Over time this trains the team to approve snapshot diffs without reading them, which defeats the point of having the test.

Snapshots earn their place for output that is genuinely stable and where any change is worth a human glance: a rendered email template, a generated CSS-in-JS class list, or a complex SVG chart. For everyday UI components, an explicit assertion ("the error message contains this text", "the button is disabled") documents intent far better than a blob of serialized markup ever will.

Testing hooks in isolation

Custom hooks that encapsulate real logic, debouncing, pagination state, a useLocalStorage wrapper, deserve tests independent of any component that happens to use them. @testing-library/react ships renderHook for exactly this, so you do not need to build a throwaway component just to exercise a hook.

// useDebouncedValue.test.ts
import { act, renderHook } from "@testing-library/react";
import { useDebouncedValue } from "./useDebouncedValue";

jest.useFakeTimers();

it("only updates the debounced value after the delay", () => {
  const { result, rerender } = renderHook(
    ({ value }) => useDebouncedValue(value, 300),
    { initialProps: { value: "a" } },
  );

  rerender({ value: "ab" });
  expect(result.current).toBe("a");

  act(() => {
    jest.advanceTimersByTime(300);
  });

  expect(result.current).toBe("ab");
});

Fake timers are the one place I will let a test know something about implementation, because the alternative, real setTimeout waits in a CI pipeline, makes the suite slow and occasionally flaky under load.

Production pitfalls worth knowing before they cost you a day

Tests that pass locally but fail in CI are almost always a timing problem: something updated asynchronously and the assertion ran before it. findBy queries and waitFor exist specifically for this; reaching for arbitrary setTimeout delays in a test is a sign the test is fighting the tool instead of using it.

Overusing act() warnings as a signal to wrap everything in act manually usually means an async state update is happening outside of what Testing Library's utilities already track. Fix the root cause, usually a missing await on a user interaction or a data fetch, rather than silencing the warning.

Testing against data-testid everywhere instead of roles and labels quietly disconnects your tests from accessibility. It works, but it stops your test suite from doing double duty as an accessibility check, and it produces markup that is harder to read for both people and assistive technology.

Coverage percentage as a target rather than a signal leads to tests that call a function and assert nothing meaningful, just to light up a line as covered. A high number with weak assertions is worse than a lower number with tests that actually verify behavior, because it gives false confidence.