Test a React component fetching async data on mount
Whether you can assert on asynchronous DOM updates without race conditions. Mock the API, render, then use findBy or waitFor to assert on loading and loaded states. Red flag: using getBy right after render or forgetting to await async queries.
What's really being asked
This tests your understanding of the React Testing Library async mental model. Interviewers want to see that you know why getBy queries fail on elements that do not yet exist, and how to use the library's built-in retry mechanisms to avoid brittle tests. They also care whether you isolate the component from real network requests and whether you assert on intermediate states like loading spinners.
The full answer
A strong answer follows four steps in order. First, mock the API so the test is deterministic and fast, using something like MSW or jest.mock. Second, render the component and optionally assert the immediate loading state with getBy or queryBy if the loading indicator is present synchronously. Third, wait for the async data to appear using findBy queries, which combine getBy and waitFor, or use waitFor directly when asserting on mock call counts or non-element conditions. Fourth, assert the final list content and any side effects, then clean up if needed. Mention that findBy returns a Promise and must be awaited.
The mistakes people make
Red flags include using getBy right after render to grab elements that will appear after the fetch, which throws because the element is not in the DOM yet. Another mistake is forgetting to await findBy or waitFor, causing the test to pass before the assertion actually runs. Some candidates suggest using setTimeout or arbitrary delays, which makes tests flaky and slow. A third anti-pattern is hitting a real API instead of mocking it, which removes determinism.
What usually comes next
The interviewer might ask how you would test the error state, which can be done by making the mock reject and asserting on an error message with findByText. They might also ask about testing disappearance, where waitForElementToBeRemoved is useful for hiding loading spinners. Another follow-up is how to test a refetch triggered by a user action, which again uses findBy after firing an event.
A concrete example
Imagine a UserList component that calls fetchUsers on mount. In the test, mock fetchUsers to return a Promise that resolves to an array of three users. Render UserList and expect screen.getByText('Loading...') to be in the document. Then write await screen.findByText('Alice') to pause the test until the resolved data renders. Optionally wrap the mock resolution in waitFor if you need to assert that fetchUsers was called exactly once. Finally assert that the list contains three list items.
Interview question
When testing a component that fetches data on mount, which approach correctly asserts the final rendered state without race conditions?
- a.Mock the API, render the component, then use screen.getByText to assert the final data immediately.
- b.Mock the API, render the component, await screen.findByText for the final data, and assert the loading state with getByText if it renders synchronously.Correct
- c.Await the render call itself, then use getByText to assert the final data once the Promise resolves.
- d.Render the component against the real API and wrap the assertion in setTimeout to wait for the network request.
Why? this is the answer
B is correct because mocking isolates the test and findBy retries until the async data appears, while getBy is safe for the synchronous loading state. A is tempting but wrong because getBy throws if the element has not yet appeared after the initial render.
Just read this? Test yourself on what you have been reading.
Read the original → testing-library.com
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on react — each one lists the topics its interview covers.
See open roles