A React component renders a user's name only after a fetch promise resolves. In a React Testing Library test, which query do you use to assert that the name appeared, and what must you do with the value that query returns?
answer
- the query family that returns a promise
- retries until the DOM matches
- one second is the default budget
- forget await and you assert on a Promise
basics
~20 sUse an async findBy* query, such as screen.findByText('Ada Lovelace'), and await it. It returns a promise that retries the query until the element appears or a default 1000 ms timeout expires; unawaited, you assert on a promise instead of the DOM.
solid answer
~50 sFor anything that appears after a promise resolves, reach for the `findBy*` family — `await screen.findByText('Ada Lovelace')`. A `findBy*` query is the synchronous query plus a retry loop: it re-runs the query whenever the DOM mutates and on a short interval, resolving with the element as soon as it matches, and rejecting with a useful "unable to find" error plus a DOM dump if nothing matches within the default one-second timeout. The critical part is `await`. Without it you hold a pending promise, so `expect(...).toBeInTheDocument()` runs against a Promise object rather than an element, and the state update that eventually resolves lands after your test finished — which is where the "not wrapped in act" warnings and stray unhandled rejections come from. `findAllBy*` behaves the same but resolves with an array as soon as at least one match exists.
code
javascript · 7 linesimport { render, screen } from '@testing-library/react'
import UserCard from './UserCard'
test('renders the fetched name', async () => {
render(<UserCard userId="1" />)
expect(await screen.findByText('Ada Lovelace')).toBeInTheDocument()
})go deeper
Know that findBy* queries return promises and must be awaited, and that they are the right tool whenever content appears after a fetch. Never reach for a manual sleep before a synchronous query.
Be ready to explain that findBy* is the synchronous query wrapped in a retry loop driven by a MutationObserver and an interval, with a 1000 ms default deadline, and to show the three-argument form that overrides that timeout.
Show the diagnosis: an unawaited async query is why act warnings and unhandled rejections appear in a test that is not the one at fault. Explain how you would find and fix those across an existing suite.
Own the standard: lint rules that make unawaited queries a build failure, a default timeout the team does not casually raise, and the position that repeated timeout bumps are a determinism problem disguised as a configuration problem.
## The problem: the DOM at t=0 is not the DOM you are asserting about A component that fetches on mount renders twice, at minimum: once immediately (empty, skeleton, or loading state) and again after the promise resolves and React re-renders. `render()` returns after the first of those. Any assertion written on the next line runs against the *first* DOM, which does not yet contain the fetched name. The test does not need a longer sleep — it needs a query that keeps looking. ## What findBy* actually is Every async query in Testing Library is defined as the synchronous query wrapped in the `waitFor` helper. `findByText(...)` is roughly `waitFor(() => getByText(...))`. That gives it three properties worth stating explicitly: - **It returns a promise.** Nothing in it is synchronous. - **It retries.** The underlying `waitFor` observes the container with a `MutationObserver` and also polls on an interval (50 ms by default), re-running the query each time something could have changed. - **It has a deadline.** The default is 1000 ms, exposed as the `asyncUtilTimeout` configuration value. On timeout it rejects with the same readable error a `getBy*` failure produces, including a printout of the DOM it searched, which is usually enough to see that you were waiting on the wrong text. ```js expect(await screen.findByText('Ada Lovelace')).toBeInTheDocument() ``` Because the query itself throws a descriptive error on failure, the `expect` around it is close to redundant — many teams write `await screen.findByText('Ada Lovelace')` on its own line and treat the absence of a rejection as the assertion. ## Why the await is not optional Dropping the `await` breaks the test in two directions at once. Forward: `expect(somePromise).toBeInTheDocument()` is asserting on a promise object, and depending on your matcher set it either fails with a confusing message or, worse, silently passes a truthiness-shaped check. Backward: the retry loop is still running after the test function returns. When the fetch resolves and React sets state, it does so in a component belonging to a test that has already finished — React emits the "An update to X inside a test was not wrapped in act(...)" warning, the failure surfaces in a *different* test's output, and the suite becomes hard to read. Linting helps here; the `await-async-queries` rule in eslint-plugin-testing-library exists precisely because this mistake is invisible when the test happens to pass. ## Passing options The async queries take the query options as the second argument and the wait options as the third, so a slower path is expressed as: ```js await screen.findByText('Ada Lovelace', {}, { timeout: 3000 }) ``` The empty object in the middle is the query options slot. You can also move the default globally with `configure({ asyncUtilTimeout: 3000 })`, but a global bump slows every failing test in the suite by the same factor, so a local option with a comment is usually the better trade. ## findAllBy* and the "at least one" rule `findAllBy*` resolves with an **array** and is satisfied as soon as one element matches. If the component streams in rows, it can resolve when three of the expected ten have rendered. When the count matters, wait for something that only exists in the final state — a total label, an enabled button — rather than asserting the array length straight out of `findAllBy*`. ## What findBy* does not do It does not wait for the network, a timer, or a promise; it only watches the DOM. If the component never renders the text — wrong prop, mock not wired, error branch taken — you get a one-second delay and then a failure, which is the correct outcome. And it is not a substitute for making the test deterministic: an arbitrary `setTimeout` sleep before a synchronous `getBy*` is the anti-pattern that `findBy*` replaces, because a sleep is simultaneously too long on a fast machine and too short on a loaded CI runner.
- What actually goes wrong if you forget the await on a findBy query?Two things. The assertion runs against a pending promise rather than an element, so it proves nothing. And the retry loop plus the component's state update outlive the test, producing an "update not wrapped in act" warning or an unhandled rejection that surfaces in an unrelated test. The eslint rule `await-async-queries` catches it mechanically.
- How would you wait longer for one query you know is slow?Pass wait options as the third argument: `await screen.findByText('Report ready', {}, { timeout: 5000 })`. Prefer that over `configure({ asyncUtilTimeout })`, which raises the deadline for every test and multiplies the cost of every genuine failure. And first ask why it is slow — an unmocked request or a real timer is a determinism bug, not a timeout bug.
- If several rows appear one by one, is findAllByRole('row') a safe way to assert there are ten?No. `findAllBy*` resolves as soon as at least one element matches, so it can return three rows mid-stream and the length assertion fails intermittently. Wait for a marker that exists only in the settled state — a "10 results" label, an enabled Next button — and then read the rows synchronously.
saying these in an interview costs you the question
- Adding setTimeout or a sleep before a getBy assertion
- Calling findByText without awaiting the returned promise
- Thinking findBy re-renders or re-invokes the component
- Believing findBy waits on the network rather than the DOM
- Asserting findAllBy length while items still stream in