Testing Components That Fetch Data

The plain-language idea

Testing a component that fetches data has a few concerns specific to it that plain component tests don't — mostly because the thing being tested is inherently asynchronous and has more than one real state to render correctly.

Two habits separate a data-fetching test suite that actually catches bugs from one that just looks thorough:

• Mock at the network boundary, not your own fetching code. Intercepting the actual HTTP request/response — rather than replacing your own wrapper function with a fake that returns data directly — means the test exercises your real request-building and response-parsing code, not a version of it you've assumed works. A mocked wrapper function can drift out of sync with what the real function does; a mocked network response can't, because the real code still runs against it.
• Test every state from the fetch lifecycle, not just success-with-data. The earlier lesson on the fetch lifecycle's loading/success/error/empty states isn't just a UI modeling concern — it's a literal test-case checklist. A suite that only covers "renders correctly once data arrives" hasn't actually verified the other three states exist and render correctly at all.

See it in a real thing: a test suite for a data-fetching component

// Intercepting at the network boundary, not mocking fetchPosts() directly
describe("PostList", () => {
  it("shows a loading state while the request is pending", () => {
    mockNetwork.get("/posts").respondWith({ delayMs: Infinity }); // never resolves
    render(<PostList />);
    expect(screen.getByRole("status")).toHaveTextContent(/loading/i);
  });

  it("renders posts once the request resolves", async () => {
    mockNetwork.get("/posts").respondWith({ status: 200, body: [{ id: "1", title: "Hello" }] });
    render(<PostList />);
    await screen.findByText("Hello"); // waits for the async work to actually settle
  });

  it("renders an error state when the request fails", async () => {
    mockNetwork.get("/posts").respondWith({ status: 500 });
    render(<PostList />);
    await screen.findByText(/something went wrong/i);
  });

  it("renders a no-results state when the request succeeds with zero items", async () => {
    mockNetwork.get("/posts").respondWith({ status: 200, body: [] });
    render(<PostList />);
    await screen.findByText(/no posts yet/i);
  });
});

Four tests, four distinct states — and the empty-success case is the one most suites skip entirely, because it's easy to assume "success with an empty array" just falls out of the happy-path test for free. It doesn't; it's genuinely a different render branch, and a component with a bug there (rendering the loading spinner or the error message for a legitimately empty result) will pass every other test in this suite while being wrong in production.

What people usually miss

Watch out

• Mocking your own fetch wrapper instead of the network tests a fake, not your code. If the wrapper has a bug in how it builds the request or parses the response, a test that replaces the wrapper entirely with a stub never runs that code and never catches the bug.
• The empty-success state is not covered by the happy-path test, even though it feels like it should be. "Has data" and "succeeded with zero items" are different render branches and need their own explicit test.
• A query/assertion helper that waits (like find*-style queries) is not optional polish — it's what makes an async test correct instead of flaky. Reaching for an immediate, non-waiting assertion after triggering an async fetch is the single most common cause of intermittent test failures in this category.
• Testing only the loading state's existence isn't the same as testing it renders correctly. A test that only checks a loading indicator is present, without also covering that the component still transitions correctly to error or empty afterward, misses regressions where a component gets stuck loading forever — the exact bug the fetch-lifecycle lesson warned about.

Why this matters in interviews

"How would you test a component that fetches data?" is a real, common question, and naming network-boundary mocking plus all four fetch-lifecycle states — not just "I'd mock the API and check it renders" — is what shows you've actually caught a flaky or incomplete test in a real codebase before.