The act(...) warning, caused and fixed
The leaky test passes, then React reports a state update that happened after it, outside act. The fixed test awaits the final heading: findBy runs inside act, so the update is expected and no warning appears.
Async UI is tested by waiting for what the user will finally see with findBy and waitFor; the network is replaced with fakes (injected functions, vi.fn/vi.mock, or MSW), timers with fake timers, and an act(...) warning means an update happened that your test didn't wait for.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write a test (live helper style) for a Weather component that receives getWeather and shows Pune: 31 °C. Use a fake that resolves after 100 ms.
Write the MSW handler and a test override that makes GET https://api.example.com/todos return an empty array, and assert the component shows No todos yet.
Explain it without notes
How do you test a component that loads data in an effect?
Compare injecting a fake, vi.mock, and MSW for mocking network calls.
What does the "not wrapped in act(...)" warning mean and how do you fix it properly?
How do fake timers work and what do you need to do when combining them with user-event?
Preview
Console
Nothing logged yet.Expected console output
✓ leaky: checks the loading text and stops
An update to Profile inside a test was not wrapped in act(...).
When testing, code that causes React state updates should be wrapped into act(...):
act(() => {
/* fire events that update state */
});
/* assert on the output */
This ensures that you're testing the behavior the user would see in the browser. Learn more at https://react.dev/link/wrap-tests-with-act
✓ fixed: waits for what the user finally sees