Everything in this section so far applies to React unchanged, because React Testing Library is a thin layer over the same queries and user-event you already know. The genuinely new part is the network: React components love to fetch, and how you fake that decides whether your tests catch real bugs.
\nSplitwise-lite’s ExpenseList takes expenses as a prop and has one piece of state, a search filter:
import { useState } from 'react';\nimport { formatMoney } from './money.js';\n\nexport function ExpenseList({ expenses }) {\n const [query, setQuery] = useState('');\n const visible = expenses.filter((e) =>\n e.description.toLowerCase().includes(query.trim().toLowerCase()),\n );\n\n return (\n <section aria-label=\"Expenses\">\n <label>\n Search <input value={query} onChange={(e) => setQuery(e.target.value)} />\n </label>\n {visible.length === 0 ? (\n <p>No matching expenses</p>\n ) : (\n <ul>\n {visible.map((e) => (\n <li key={e.id}>{e.description}: {formatMoney(e.amountCents)}</li>\n ))}\n </ul>\n )}\n </section>\n );\n}With @testing-library/react installed and environment: 'jsdom', tests read like the DOM tests you’ve written:
import { test, expect } from 'vitest';\nimport { render, screen } from '@testing-library/react';\nimport userEvent from '@testing-library/user-event';\nimport { ExpenseList } from './ExpenseList.jsx';\n\nconst expenses = [\n { id: 'e1', description: 'Dinner', amountCents: 4550 },\n { id: 'e2', description: 'Taxi', amountCents: 1800 },\n];\n\ntest('filters expenses as you type', async () => {\n const user = userEvent.setup();\n render(<ExpenseList expenses={expenses} />);\n\n await user.type(screen.getByRole('textbox', { name: 'Search' }), 'tax');\n\n const items = screen.getAllByRole('listitem');\n expect(items.map((li) => li.textContent)).toEqual(['Taxi: $18.00']);\n});\n\ntest('shows the new expense when the prop changes', () => {\n const { rerender } = render(<ExpenseList expenses={expenses} />);\n\n rerender(<ExpenseList expenses={[...expenses, { id: 'e3', description: 'Museum', amountCents: 2400 }]} />);\n\n expect(screen.getByText('Museum: $24.00')).toBeTruthy();\n});Props are tested by rendering with different values (and rerender for updates). State is tested by interacting and checking the result; there’s no way to read query from the test, and that’s a feature. render wraps updates in React’s act() for you, and React Testing Library unmounts components after each test when Vitest’s globals option is on (otherwise call cleanup in an afterEach).
A component that loads a group calls a data function, which calls fetch, which goes over the network. You can cut that chain at three points:
vi.mock('./load-group.js')) skips the URL building, status handling and response shaping. Those are exactly where the bugs are.fetch (loadGroup(id, fetchImpl)) runs all of your code and fakes only the transport. Simple, no library, and what the exercise uses.fetch, unchanged:import { setupServer } from 'msw/node';\nimport { http, HttpResponse } from 'msw';\n\nexport const server = setupServer(\n http.get('https://api.splitwise-lite.test/groups/:id', ({ params }) =>\n HttpResponse.json({ name: `Group ${params.id}`, members: [], expenses: [] }),\n ),\n);In a setup file, call server.listen({ onUnhandledRequest: 'error' }) before all tests, server.resetHandlers() after each, and server.close() at the end. A single test overrides a route with server.use(http.get(..., () => new HttpResponse(null, { status: 404 }))) to test the error path. The same handlers can power your app in development and in Storybook, so the fake API stays in one place.
Some component tests cost more than they catch. Skip them:
\ntext-red-600 or the padding is 12px. Visual regressions are better caught by screenshot tests in a real browser, or a human review.onChange.expect(container).toMatchSnapshot() on a large component fails on every harmless markup change, and reviewers learn to press “update snapshot” without reading. A small inline snapshot of one formatted value can be fine; a 300-line one is noise.A good network test checks what you sent as well as what you did with the answer. A wrong URL is a real bug (/group/ instead of /groups/), and only an assertion on the request catches it, since your fake happily answers anything. With an injected fetch that’s expect(fetchMock).toHaveBeenCalledWith('https://api.splitwise-lite.test/groups/lisbon'); with MSW, the handler only matches the right path, and onUnhandledRequest: 'error' fails the test for anything else.
In the exercise you test loadGroup with an injected fetch that returns real Response objects, and catch four bugs in the request and the response shaping. That completes the UI section. Next comes the real browser, where layout, routing and the real server finally meet.
render mounts a component into the jsdom document; you query and interact with it exactly as with plain DOM.","Test props by rendering with different props (or rerender) and state by interacting; never reach into state or hooks directly.","Mock the network at its edge, either by injecting fetch or by intercepting requests with MSW, so your own data-shaping code still runs in the test.","Assert on the request you sent (URL, method) as well as on what the UI or function does with the response, including error statuses."],"further":[{"title":"Testing Library — React Testing Library","url":"https://testing-library.com/docs/react-testing-library/intro"},{"title":"Testing Library — React Testing Library API","url":"https://testing-library.com/docs/react-testing-library/api"},{"title":"MDN — Response","url":"https://developer.mozilla.org/en-US/docs/Web/API/Response"},{"title":"Vitest — Mocking requests","url":"https://vitest.dev/guide/mocking/requests"}],"quiz":[{"q":"How should a test check that ExpenseList filters as you type in the Search box?
query state after typing and check it equals the typed text.","why":"State is an implementation detail; a component can store the right text and still render the wrong list."},{"text":"Call the setQuery function directly and snapshot the result.","why":"Tests can’t (and shouldn’t) reach a component’s state setters; and a snapshot wouldn’t say which items should be visible."}],"answer":0},{"q":"Why do many teams prefer MSW over vi.mock('./api.js') for components that fetch data?
vi.mock doesn’t work in files that render React components.","why":"vi.mock works anywhere; the issue is how much real code it skips."},{"text":"MSW intercepts at the network level, so your real fetch and data-shaping code still run in the test.","why":"Correct. With a module mock, a bug in how you build the URL or parse the response is replaced away; with MSW it is exercised."}],"answer":2},{"q":"loadGroup forgot to check response.ok. For a 404, the JSON is { "error": "Not found" }, so the code throws Cannot read properties of undefined. Which assertion catches the missing check?
await expect(loadGroup('nope', fetchMock)).rejects.toThrow()","why":"The buggy version rejects too, with a TypeError, so an assertion that accepts any error passes."},{"text":"await expect(loadGroup('nope', fetchMock)).rejects.toThrow('HTTP 404')","why":"Correct. Matching the message proves the status was checked, not that something else happened to blow up."},{"text":"expect(fetchMock).toHaveBeenCalledTimes(1)","why":"Both versions call fetch exactly once; the difference is what they do with the response."}],"answer":1}],"exercise":{"kind":"web","mode":"test","subject":"const API = 'https://api.splitwise-lite.test';\n\n// Loads a group: GET `${API}/groups/loadGroup(groupId, fetchImpl) requests https://api.splitwise-lite.test/groups/<id>, converts the API’s JSON (dollars, snake_case) into Splitwise-lite’s shape (cents, camelCase), and rejects with Could not load group <id> (HTTP <status>) when the response isn’t ok. The exact shapes are in the subject’s comment.
The starter gives you jsonResponse(body, status), which builds a real Response, and an apiGroup sample. Pass a vi.fn().mockResolvedValue(jsonResponse(...)) as fetchImpl and add tests until your suite catches four hidden bugs: one ignores the HTTP status, one requests the wrong URL, one forgets to convert dollars to cents, and one reads paidBy from the wrong field.
expect(fetchMock).toHaveBeenCalledWith('https://api.splitwise-lite.test/groups/lisbon').","Compare the whole result with toEqual; the expected object is spelled out in the subject comment (45.5 dollars is 4550 cents).","For the error path, use jsonResponse({ error: 'Not found' }, 404) and assert the message, not just that it rejects: the buggy version rejects too, with a TypeError."],"explanation":"Because only the transport is faked, every line of loadGroup runs in the test. toHaveBeenCalledWith on the fetch mock catches the wrong URL, which no assertion on the result could see, since a fake answers any URL. One toEqual on the converted group catches both shaping bugs: dollars left as 45.5 and paidBy coming back undefined. The 404 test is the subtle one: without the ok check, the code still rejects, with Cannot read properties of undefined, so only matching the message HTTP 404 proves the status was handled on purpose. This is the same discipline MSW gives you, without the library.