One slow test in the suite is still hitting the real network

One test in the suite is slower than the rest, and it fails whenever the network hiccups, because it's calling the real API.

Beginner to intermediateRead 7 minDoing: about an hour7 steps

▶ Start

What you'll have at the end

A component test with fetch mocked and canned data returned, so it never leaves the machine

Before you start

You need

A component test suite that already renders and queries a component whose data-loading effect calls a small, separately exported async function wrapping fetch, with at least one currently-passing test that leaves that function untouched and therefore reaches the real network.

Not covered

Rendering the component's own loading and error states with Testing Library queries, or intercepting requests below fetch with a dedicated mocking server; this recipe only replaces the loader's own call to fetch.

Leans on

7 steps

Where to go next

Stub a browser API jsdom never implemented

when the missing piece is a browser API jsdom never built, like matchMedia, rather than a network call

The same test fails in CI and passes on your laptop

when a test's real dependency is the environment itself rather than the specific data a call returns

Checked 25 Aug 2026

Part of the Vitest Testing Framework cookbook