Top 34 React Testing Library Interview Questions and Answers [2026]

Queries and Guiding Principles

1. What is the guiding principle of Testing Library, and how does it change the tests you write?

"The more your tests resemble the way your software is used, the more confidence they can give you."

In practice that means a test renders a component, finds elements by what a user sees or hears (role, accessible name, label, text), interacts the way a user would, and asserts on visible output.

It does not reach into component state, call instance methods or check which hook ran.

The payoff is refactor resistance. A test that finds the submit button by getByRole('button', {name: /save/i}) survives a rewrite from class components to hooks, a CSS module change and a move to a design system button.

A strong candidate adds the second-order benefit: if a query by role cannot find the element, the markup probably has an accessibility problem too, so the test doubles as a cheap a11y check.

2. In what order should you reach for queries?

The queries documentation sets a priority in three groups:

• Accessible to everyone: getByRole first, then getByLabelText (best for form fields), getByPlaceholderText, getByText for non-interactive content, and getByDisplayValue.
• Semantic queries: getByAltText and getByTitle. The docs warn that the title attribute is read inconsistently by screen readers.
• Test IDs: getByTestId, for cases where neither role nor text can identify the element.

A weak answer says "I use test IDs because they are stable."

A strong one explains that placeholder text is a fallback because a placeholder is not a label, and names legitimate uses for test IDs: a canvas chart, a third-party widget with no roles, or a container that only exists for layout.

Setting configure({throwSuggestions: true}) makes the library throw when a better query exists, which is a useful tool in a codebase migrating off test IDs.

3. What is the difference between getBy, queryBy and findBy?

They differ in what happens with zero matches and whether they retry:

• getBy* returns the element, and throws on zero or more than one match. Use it for elements that must already be there.
• queryBy* returns null on zero matches, and still throws on more than one. Use it only to assert absence.
• findBy* returns a promise that retries a getBy* until it passes or times out. Use it for elements that appear after async work.

The *AllBy* variants return arrays and do not throw on multiple matches. Interviewers often ask the follow-up: why does queryBy* throw on multiple matches?

Because a query that silently returned the first of several matches would hide ambiguous markup, and an absence check that passes because the wrong element was found is worse than a failure.

4. Why prefer screen over the queries returned by render?

screen exposes every query bound to document.body, so the test does not need to destructure render's return value and keep that list in sync as queries change.

It reads closer to what a user sees: the whole page, not the component's container. Portals, modals and toasts that render outside the component's container are found by screen and missed by container-bound queries.

render's result still matters for rerender, unmount and container.

The docs note that screen needs a global DOM environment, such as Jest's jsdom test environment or Vitest's environment: 'jsdom'. screen.debug() prints the DOM, and screen.logTestingPlaygroundURL() gives a link that suggests queries for the current markup.

5. How does getByRole compute the accessible name, and what does the hidden option do?

getByRole matches an element's implicit or explicit ARIA role, and the name option matches its accessible name as computed from aria-labelledby, aria-label, an associated <label>, text content or alt, depending on the element.

A button with only an SVG icon has no name unless it has an aria-label, so getByRole('button', {name: 'Close'}) fails, which is the right result.

By default, getByRole excludes elements hidden from the accessibility tree: display: none, visibility: hidden, the hidden attribute and aria-hidden="true". Passing hidden: true includes them.

Other options worth knowing are level for headings, checked, pressed, selected and expanded for state.

A senior candidate also mentions cost: getByRole walks the tree and computes styles, so on DOMs with thousands of nodes it is the slowest query, and scoping it with within keeps suites fast.

6. When do you use within?

within(element) returns the full query set bound to that element.

Use it when the same text or role appears more than once on the page: a table where each row has a "Delete" button, a list of cards each with a "Buy" link, or a dialog that repeats a label from the page behind it.

const row = screen.getByRole('row', {name: /invoice 1042/i})
await user.click(within(row).getByRole('button', {name: /delete/i}))

const dialog = await screen.findByRole('dialog', {name: /confirm delete/i})
expect(within(dialog).getByText(/cannot be undone/i)).toBeInTheDocument()

Without within, candidates fall back to getAllByRole('button')[3], which breaks the moment rows are re-sorted. That index is a good thing to flag in a code review question.

7. How do text matchers work, and what do exact and normalizer change?

Text queries accept a string, a regex or a function. A string matches the full, trimmed text with whitespace collapsed, and is case-sensitive by default. {exact: false} switches to a case-insensitive substring match.

A regex such as /order placed/i is the usual middle ground: case-insensitive and partial, but explicit about it.

The default normalizer trims and collapses whitespace; a custom normalizer can also strip non-breaking spaces or currency formatting.

A function matcher (content, element) => ... handles text split across elements, such as <p>Total: <strong>$40</strong></p>, where getByText('Total: $40') fails because no single element has that exact text content.

Strong candidates reach for a role or label query before writing a function matcher.

Async Utilities and act()

13. How does waitFor work, and what are its defaults?

waitFor(callback) runs the callback once immediately, then again every 50 ms and on every DOM mutation, until it stops throwing or the timeout passes.

The async API docs give the defaults: timeout 1000 ms (from the global asyncUtilTimeout config), interval 50 ms, and a MutationObserver watching subtree, child list, attributes and character data.

Two details trip up candidates. A callback that returns false does not trigger a retry; only a thrown error does, so waitFor(() => mock.mock.calls.length === 1) passes at once.

And on timeout, the error message includes the printed DOM, which is the first place to look when a CI run fails.

14. What should and should not go inside a waitFor callback?

Put one assertion inside, and keep side effects outside. The callback can run dozens of times, so a click or a fetch inside it repeats on every retry.

• One assertion per waitFor. With several, the test waits for all of them and a failure reports only the first, which slows feedback.
• No side effects. Interactions go before the waitFor.
• Not empty. await waitFor(() => {}) passes on the first tick and only hides an act warning.
• Prefer findBy* when the thing being waited for is an element: await screen.findByRole('alert') replaces await waitFor(() => expect(screen.getByRole('alert')).toBeInTheDocument()).

waitFor stays the right tool for non-DOM conditions, such as a mock having been called with specific arguments.

15. How do you assert that something disappears?

Use waitForElementToBeRemoved for elements that are present and will go away, such as a spinner, and queryBy* with not.toBeInTheDocument() for elements that should never appear.

render(<Orders />)
await waitForElementToBeRemoved(() => screen.queryByRole('progressbar'))
expect(screen.getAllByRole('row')).toHaveLength(4)

Per the docs, waitForElementToBeRemoved throws if the element is already gone, or if its argument is null or an empty array, when it is called. That makes it fail loudly when a spinner never rendered.

The callback form re-queries on each check, which avoids holding a stale reference to a node React has already replaced.

16. What does "An update to X inside a test was not wrapped in act(...)" mean, and how do you fix it?

React detected a state update that happened outside an act() scope while the test environment says act is expected.

In a Testing Library test, render, fireEvent, user-event calls and the async utilities already run inside act, so the warning almost always means an update landed after the test stopped waiting: a fetch resolved, a timer fired, or a promise chain settled after the last assertion.

The fix is to wait for the result of that update, not to wrap more code in act:

• Await the UI the update produces: await screen.findByText(/loaded/i).
• Under fake timers, advance timers inside act or let user-event advance them.
• If the update is a side effect the test does not care about, mock the source so it resolves predictably, then wait for its visible result.

Weak answers wrap the whole test in act(async () => ...) or add await waitFor(() => {}). Both silence the warning and leave a test that asserts on a half-updated UI.

17. What is IS_REACT_ACT_ENVIRONMENT, and who sets it?

It is a global flag that tells React whether it runs in a test environment that uses act.

When it is true, React warns about unwrapped updates; when it is not set and code calls act, React warns that "the current testing environment is not configured to support act(...)".

React Testing Library sets it to true in a beforeAll hook when the runner exposes global beforeAll and afterAll, and restores the previous value afterwards.

Its asyncWrapper sets it to false while waitFor runs, because polling the DOM from outside act is the point of waitFor.

A candidate who knows this can explain why a custom test harness without globals, or code that calls act from react outside RTL, suddenly prints environment warnings, and set globalThis.IS_REACT_ACT_ENVIRONMENT = true in the setup file as the fix.

18. Why can waitFor hang under Vitest fake timers but not under Jest's?

DOM Testing Library only advances fake timers itself when it detects Jest's: the check looks for a global jest object and a faked setTimeout.

When it finds them, waitFor loops, calling jest.advanceTimersByTime(interval) inside act between checks.

Under Vitest there is no jest global, so waitFor takes the real-timers path, and its 50 ms setInterval and its overall timeout are themselves faked. If no DOM mutation arrives, the callback never re-runs and the timeout never fires.

Fixes a candidate should offer:

• vi.useFakeTimers({shouldAdvanceTime: true}), so fake time moves with real time.
• Advance time explicitly with await vi.advanceTimersByTimeAsync(ms) before asserting, and assert with getBy* instead of polling.
• Fake only the timers the code under test uses, with the toFake option.

19. Find the bug: a test that passes locally and flakes in CI.

test('shows search results', async () => {
  const user = userEvent.setup()
  render(<Search />)
  user.type(screen.getByRole('searchbox'), 'laptop')
  await waitFor(() => {
    user.click(screen.getByRole('button', {name: /search/i}))
    expect(screen.getByText(/3 results/i)).toBeInTheDocument()
  })
})

Bugs:

• user.type is not awaited. Typing is async in v14, so the click can run before all six characters are in the field. Locally the machine is fast enough; in CI it is not.
• A side effect inside waitFor. The click runs on every retry, so the component may fire several searches, and the test passes on whichever response lands first.
• Unawaited click. The click promise is dropped, so its errors surface as unhandled rejections or act warnings in a later test.

Fix: await user.type(...), await user.click(...), then expect(await screen.findByText(/3 results/i)).toBeInTheDocument(). The eslint-plugin-testing-library rules await-async-events and no-wait-for-side-effects catch both patterns.

Network Mocking and Runner Setup

26. Why mock the network with MSW instead of mocking fetch or the API module?

MSW intercepts requests at the network layer, so the component, its data library and its fetch client all run for real, and the test only replaces the server.

Mocking fetch by hand couples the test to the exact call shape; mocking the API module skips the serialization, headers and error handling where bugs live. The same handlers serve tests, Storybook and local development.

// src/mocks/handlers.js
import {http, HttpResponse} from 'msw'

export const handlers = [
  http.get('/api/orders', () =>
    HttpResponse.json([{id: 1042, total: 40}]),
  ),
]

// test setup file
import {setupServer} from 'msw/node'
import {handlers} from './src/mocks/handlers'

export const server = setupServer(...handlers)
beforeAll(() => server.listen({onUnhandledFrame: 'error'}))
afterEach(() => server.resetHandlers())
afterAll(() => server.close())

In MSW 3 the option that fails on unmocked traffic is onUnhandledFrame (default 'warn'), renamed from onUnhandledRequest because it now covers WebSocket connections as well as HTTP requests (see the listen() docs).

Setting it to 'error' stops a test from silently hitting a real endpoint.

27. Find the bug: the error-state test breaks the next test.

// setup file: beforeAll(() => server.listen()); afterAll(() => server.close())

test('shows an error when orders fail', async () => {
  server.use(
    http.get('/api/orders', () => new HttpResponse(null, {status: 500})),
  )
  render(<Orders />)
  expect(await screen.findByRole('alert')).toHaveTextContent(/try again/i)
})

test('lists orders', async () => {
  render(<Orders />)
  expect(await screen.findByText('#1042')).toBeInTheDocument()
})

Bug: the setup file has no afterEach(() => server.resetHandlers()), so the 500 override from server.use stays active and the second test gets an error. Run the second test alone and it passes, which is the signature of leaked state.

Fix: reset handlers after each test, or scope the override with {once: true} on the handler. A strong candidate also mentions the other shared state in this pair: a data library cache.

If Orders uses a query client created at module scope, the cached error or data crosses tests too, which is why question 24 builds a new client per render.

28. How do you set up jest-dom and Testing Library for Vitest compared with Jest?

The libraries are the same; the setup file and globals differ.

• Jest: testEnvironment: 'jsdom' (install jest-environment-jsdom separately), and import '@testing-library/jest-dom' in a file listed in setupFilesAfterEnv. Jest exposes afterEach globally, so RTL's auto cleanup runs.
• Vitest: environment: 'jsdom' or 'happy-dom', setupFiles: ['./vitest.setup.ts'], and import '@testing-library/jest-dom/vitest', which extends Vitest's expect and its types.

The Vitest trap is globals. Vitest does not expose afterEach globally unless globals: true is set, and RTL registers its automatic cleanup only when a global afterEach exists.

Without it, components from earlier tests stay mounted, and later tests fail with "Found multiple elements".

The fix is globals: true or an explicit afterEach(cleanup) in the setup file. jest-dom 7 requires Node.js 22 and lists @testing-library/dom as a required peer, so upgrading it in an old toolchain can fail at install.

29. jsdom, happy-dom or a real browser: how do you choose?

jsdom and happy-dom are JavaScript implementations of the DOM that run in Node.

They are fast and cover most component behavior, but they do no layout, so anything that depends on geometry, IntersectionObserver, real CSS, canvas or focus driven by layout either needs a mock or gives false results. happy-dom is usually faster and less complete than jsdom; teams switch per file when a test needs a missing API.

For behavior that depends on a real engine, Vitest Browser Mode runs tests in Chromium, Firefox or WebKit through Playwright or WebdriverIO, and vitest-browser-react provides a render with locators modeled on Testing Library queries.

Vitest 5 made those locators exact by default, so getByText('Item') no longer matches "Item 1".

A strong candidate splits the suite: jsdom for fast logic and rendering tests, a browser for layout, drag and drop and focus traps, and end-to-end tests in Playwright for full flows.

30. Find the bug: asserting that an error message is gone.

test('clears the error after a valid email', async () => {
  const user = userEvent.setup()
  render(<SignupForm />)
  await user.type(screen.getByLabelText(/email/i), 'ada')
  await user.tab()
  expect(screen.getByText(/enter a valid email/i)).toBeInTheDocument()

  await user.clear(screen.getByLabelText(/email/i))
  await user.type(screen.getByLabelText(/email/i), 'ada@example.com')
  await user.tab()
  expect(screen.getByText(/enter a valid email/i)).not.toBeInTheDocument()
})

Bug: the last line uses getByText to check absence. getBy* throws when nothing matches, so the test fails with "Unable to find an element" at the moment the component behaves correctly.

A candidate who "fixes" it by wrapping the line in try/catch has missed the point of the query variants.

Fix: expect(screen.queryByText(/enter a valid email/i)).not.toBeInTheDocument(). If the error clears asynchronously, for example after a debounced validation, use await waitForElementToBeRemoved(...) before the next step instead.

Better still, query the field's accessible description: expect(screen.getByLabelText(/email/i)).not.toHaveAccessibleDescription(), which also tests that the error was wired with aria-describedby.

31. Do snapshot tests belong in a Testing Library suite?

Rarely, and only small ones.

A snapshot of a whole rendered page (asFragment() or container) fails on any markup change, and reviewers approve snapshot updates without reading them, so it tests that the output did not change, not that it is correct.

It also couples the test to class names and wrapper divs, which is what Testing Library tries to avoid.

Reasonable uses: a small inline snapshot of a formatter's output, a serialized error message, or a short ARIA structure where the exact tree is the contract.

A strong candidate replaces large DOM snapshots with targeted assertions such as toHaveAccessibleName, toHaveTextContent and toBeDisabled, and treats any snapshot over a screen of output as a review smell.

Signs of a Strong Answer

• They query by role and accessible name first, and treat a query that cannot find an element as a possible accessibility bug.
• They await every user-event call and every findBy*, and keep side effects out of waitFor.
• They explain an act warning as an update that landed after the test stopped waiting, and fix it by awaiting the visible result.
• They know RTL's auto cleanup and act environment depend on runner globals, and check that first when a Vitest suite shows duplicate elements.
• They mock the network with MSW, fail on unhandled traffic, and reset handlers and caches between tests.
• They can say which tests belong in jsdom, which in a real browser, and which in end-to-end tests.