How do you test React components?

Detailed explanation

I test React components by checking observable behaviour: what users can see, which controls they can operate, and how the interface changes after an action. React Testing Library is useful because it encourages tests against the rendered DOM rather than component instances, internal state, or private functions. Jest or Vitest typically runs the tests and provides mocks and assertions, while a DOM environment such as jsdom supports rendering. The jest-dom matchers add readable assertions such as toBeInTheDocument, toBeDisabled, and toHaveAccessibleName.

A typical test renders the component with realistic props and any required providers, finds a control through an accessible query, performs an interaction, and checks the outcome. Prefer getByRole with an accessible name, or getByLabelText for labelled inputs, over CSS selectors and test IDs. These queries make tests closer to how users identify controls and can expose some accessibility problems, although they do not replace accessibility testing. Create a user with userEvent.setup(), then await user.type() and user.click(). userEvent models interaction sequences more realistically than manually dispatching a single event with fireEvent.

Handle asynchronous behaviour explicitly. getBy queries are for elements expected immediately; findBy queries return promises and retry until a matching element appears. queryBy is useful for asserting absence. For a login request, enter the credentials, click Log in, and use await screen.findByText(/welcome/i) if the success message appears asynchronously. Use waitFor when an assertion needs retrying, and waitForElementToBeRemoved for a visible loading indicator that disappears. React Testing Library helpers generally handle React's act coordination; arbitrary delays usually hide synchronization problems rather than solve them.

Choose test cases around meaningful states: initial rendering, validation errors, loading, success, failure, and disabled controls. For API-backed components, mock the network boundary with a tool such as MSW instead of replacing every child or hook. Wrap components with real routing or context providers where practical, and keep tests isolated by resetting mutable test state and request handlers. Interviewers look for reliable behaviour-focused coverage, sensible mocking boundaries, and awareness that DOM tests cannot prove browser layout or complete application flows; browser-based end-to-end tests cover those gaps.

Key points to remember

• Render with React Testing Library using realistic props and required providers.
• Prefer accessible role and label queries over selectors or implementation details.
• Use userEvent.setup() and await user interactions.
• Choose getBy for immediate presence, findBy for asynchronous presence, and queryBy for absence.
• Cover meaningful UI states and mock external boundaries rather than component internals.

Common mistakes candidates make

• Asserting internal state, hook calls, or large snapshots instead of user-visible behaviour.
• Forgetting to await interactions or asynchronous UI updates, then adding fixed delays to make tests pass.
• Over-mocking children and providers so the test no longer exercises realistic component behaviour.

Likely follow-up questions