Testing and Debugging Interview Questions for React JS
25 Testing and Debugging questions with answers for react js roles — 8 easy, 11 medium, 6 hard.
About Testing and Debugging
Write tests that give real confidence. This topic covers React Testing Library queries and user-event, Vitest and Jest, mocking APIs with MSW and modules, testing hooks and components with providers, end-to-end tests with Playwright, flaky tests, act warnings, hydration errors, React DevTools and production error monitoring with source maps.
Sheet progressStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
✓ 3 questions free • Unlock the rest in seconds
01
What kinds of tests are written for a React application?
Unit tests check small pieces like utility functions, reducers and custom hooks. Component or integration tests render components with their children and check behaviour the user sees, usually with React Testing Library and Vitest or Jest. End-to-end tests run the full app in a real browser with Playwright or Cypress, covering flows like login and checkout. Static checks with TypeScript and ESLint catch many bugs before tests run.
02
What is the guiding philosophy of React Testing Library?
React Testing Library encourages testing components the way users use them, not their internal implementation. You find elements by role, label or text, interact with them through user events and assert what appears on screen. You avoid checking state variables or component instances. Its motto is that the more your tests resemble the way your software is used, the more confidence they give you, and refactors do not break them.
03
Jest or Vitest: what is the difference for React projects?
Both are test runners with a similar API (describe, it, expect, mocks). Jest is the long-established choice and still common in older projects. Vitest is built on Vite, reuses the same config and transforms, supports ESM and TypeScript natively and is much faster in watch mode, so it is the default for new Vite-based React apps. React Testing Library works with either.
04
Write a test for a counter component that increments on click.
getBy returns the element or throws immediately if it is missing, so use it when the element should exist. queryBy returns null instead of throwing, which is the right choice to assert something is not present: expect(screen.queryByText('Error')).not.toBeInTheDocument(). findBy returns a promise and retries until the element appears or times out, used for content that appears after async work. Each has an AllBy variant for multiple elements.
The Components tab shows the component tree; selecting one shows its props, state, hooks and context values, which you can edit live to test behaviour. You can find which component rendered a DOM node, view the owner chain and jump to source. The Profiler tab records renders and shows why each component re-rendered. Combined with browser breakpoints and console logs, it speeds up most UI debugging.
07
How do you respond when a senior developer leaves many comments on your pull request?
Situation: my first big PR received over twenty review comments. Task: address them and learn, not feel defensive. Action: I thanked the reviewer, fixed clear issues, asked questions on ones I did not understand and explained my reasoning politely on two where I had context. Result: the PR merged after one more round, and I created a personal checklist that reduced comments on later PRs.
08
A QA engineer raises a bug you believe is not a bug. How do you handle it?
Situation: QA reported that a filter reset on page refresh. Task: resolve it without friction. Action: I reproduced it, checked the acceptance criteria with QA and the product owner, and found the requirement was unclear rather than either of us being wrong. Result: we agreed to store filters in the URL, I implemented it in a day, and we added clearer criteria to future stories.
09
Which queries should you prefer in React Testing Library and why?
Prefer queries accessible to everyone: getByRole (with the name option) first, then getByLabelText for form fields, getByPlaceholderText, getByText and getByDisplayValue. Use getByAltText and getByTitle for images and titles. getByTestId is a last resort when nothing else works. Role-based queries also check accessibility, because if a button cannot be found by role and name, screen reader users will struggle too.
fireEvent dispatches a single DOM event, such as one change event. user-event simulates full user interactions: typing fires keydown, keypress, input and keyup for every character, clicking includes pointer and focus events, and it respects disabled elements and visibility. This finds bugs that fireEvent misses. In current versions, call userEvent.setup() and await each interaction because they are asynchronous.
11
How do you test a component that fetches data from an API?
Use vi.mock with a factory, then control return values per test.
import { vi } from 'vitest';
import { getProfile } from './api';
vi.mock('./api', () => ({
getProfile: vi.fn()
}));
test('shows name', async () => {
getProfile.mockResolvedValue({ name: 'Ravi' });
render(<Profile />);
expect(await screen.findByText('Ravi')).toBeInTheDocument();
});
In Jest, the same pattern uses jest.mock and jest.fn.
Use renderHook from React Testing Library and wrap state changes in act.
import { renderHook, act } from '@testing-library/react';
import { useCounter } from './useCounter';
test('increments', () => {
const { result } = renderHook(() => useCounter(5));
act(() => result.current.increment());
expect(result.current.count).toBe(6);
});
If the hook needs context, pass a wrapper option with the provider.
14
Your team has hundreds of snapshot tests that developers update blindly whenever they fail. What are the drawbacks of snapshot tests and what would you suggest?
A snapshot test saves the rendered output to a file and fails when future output differs. It is quick to write and catches unexpected changes. Drawbacks: large snapshots are hard to review, developers often blindly update them, and they fail on harmless markup changes while saying nothing about behaviour. Use small, focused inline snapshots for stable output, and prefer behaviour assertions for most component tests.
15
When would you add end-to-end tests with Playwright or Cypress?
Add E2E tests for critical business flows that cross many components and the backend, such as signup, login, search, add to cart and payment. They run in real browsers and catch integration issues unit tests miss. They are slower and more brittle, so keep them few and focused, use stable selectors like roles or data-testid, seed test data and run them in CI on every pull request.
16
All unit tests passed, but users found that the delete button did nothing. The tests were checking that a handleDelete function was called. What went wrong?
The tests checked implementation details instead of user-visible behaviour. A mocked handler being called says nothing about whether the item actually disappears or the API is hit. Rewrite the test to click the button by role, mock the API with MSW and assert the item is removed from the screen. Behaviour-focused tests survive refactoring and catch real bugs like a broken wiring.
17
How do you include accessibility checks in your React tests?
Use jest-axe or vitest-axe to run axe-core on rendered components.
import { axe } from 'vitest-axe';
test('form has no a11y violations', async () => {
const { container } = render(<SignupForm />);
expect(await axe(container)).toHaveNoViolations();
});
Also query by role and label in tests, run Lighthouse or axe DevTools in the browser, and test keyboard navigation manually, since automated tools catch only part of the issues.
18
How did you bring better testing practices to a team that had very few tests?
Situation: our React app had almost no tests and regressions reached production every release. Task: improve quality without slowing delivery. Action: I set up Vitest, React Testing Library and MSW, wrote example tests for two key screens, ran a short session for the team and added a rule that bug fixes include a test. Result: within three months, critical flows were covered and regressions dropped noticeably.
19
Tell me about a time you had to learn a new tool or library quickly.
Situation: our project needed to switch from Jest to Vitest with a week's notice. Task: migrate around 300 tests. Action: I read the official migration guide, migrated one folder first to discover patterns, wrote a codemod for jest.fn to vi.fn replacements and documented gotchas for the team. Result: we finished in four days, test runs became much faster, and the guide helped others with later work.
20
How do you test a component that depends on Redux and React Router?
Create a custom render helper that wraps the UI with real providers.
function renderWithProviders(ui, { route = '/', preloadedState } = {}) {
const store = configureStore({ reducer: rootReducer, preloadedState });
return render(
<Provider store={store}>
<MemoryRouter initialEntries={[route]}>{ui}</MemoryRouter>
</Provider>
);
}
Using a real store with preloaded state is better than mocking useSelector, because it tests actual behaviour.
21
Your tests pass but print 'An update to Component inside a test was not wrapped in act(...)'. What does it mean and how do you fix it?
It means state changed after the test finished checking, usually because an async operation like a fetch or timer resolved later. The test may not be checking the final UI. Fix it by awaiting the result: use findBy queries or waitFor for the expected content, await user-event calls, and use fake timers with act when testing timeouts. Do not just wrap random code in act to hide the warning.
22
In a Next.js app you see a hydration mismatch error. How do you debug it?
It means the HTML rendered on the server differs from the first client render. Common causes: using Date.now(), Math.random() or locale formatting in render, reading window or localStorage during render, browser extensions changing the DOM, and invalid HTML nesting like a div inside a p. Read the diff in the error, render client-only values inside useEffect, use useId for ids and fix invalid markup.
23
A test in CI fails randomly about one time in ten. How do you handle a flaky test?
First reproduce it by running the test repeatedly and in random order. Common causes are shared state between tests, missing awaits, real timers or dates, network calls not mocked and tests depending on execution order. Fix the root cause: reset mocks and stores in afterEach, use findBy or waitFor instead of fixed sleeps, freeze time with fake timers. Quarantine it with a ticket only temporarily, never ignore it.
24
Explain the testing pyramid and the testing trophy. Which applies to frontend?
The pyramid says write many unit tests, fewer integration tests and very few end-to-end tests, because lower tests are fast and cheap. The testing trophy, popular for frontend, adds static analysis at the base and puts the most effort in integration tests, since they give the best confidence per cost. For React, I rely on TypeScript and ESLint, many component tests, some unit tests for logic and a few E2E tests.
25
How do you track errors that happen in production React apps?
Use an error monitoring tool such as Sentry, which captures exceptions with stack traces, browser and user context. Upload source maps during the build so minified stack traces map back to your source, but do not serve them publicly. Wrap major sections in error boundaries that report errors and show friendly fallbacks. Add release tags so you can see which deployment introduced a bug.
Frequently asked questions
How important is Testing and Debugging in React JS interviews?
Write tests that give real confidence. This topic covers React Testing Library queries and user-event, Vitest and Jest, mocking APIs with MSW and modules, testing hooks and components with providers, end-to-end tests with Playwright, flaky tests, act warnings, hydration errors, React DevTools and production error monitoring with source maps.
How should I use the Testing and Debugging sheet?
Go top to bottom — easy to hard. Answer before opening each answer, tick what you solved and save misses to Last-Minute Revision.