Test behavior through the same surface a user has: render the component, query by role and accessible name, interact, and assert on what appears. Cover the logic that can actually break, such as conditional rendering, error and empty states, and custom hooks. Do not test implementation details like internal state, prop drilling, or that a child component was called; those tests break on every refactor and catch nothing.
Why interviewers ask this
The interviewer is looking for a testing philosophy rather than a tool list. They want to hear the behavior over implementation principle, sensible boundaries between unit, integration and end to end, and an opinion on mocking, since over mocked tests pass while production breaks. Naming what you skip is often more informative than naming what you cover, because it shows you have maintained a suite over time.
How to structure your answer
- State the principle: test what the user can observe.
- Describe your query and interaction style briefly.
- Say where you draw the line on mocking, especially the network.
- Name what you skip and why those tests are a liability.
Example answer
My rule is that a test should only fail when the user visible behavior changes. So I render the component with Testing Library, query by role and accessible name, click and type like a person would, and assert on what is on the screen. That has a nice side effect: if I cannot query it by role, the markup usually has an accessibility problem. For the network I intercept at the HTTP layer rather than mocking my own data layer, because mocking my own module means I am testing my mock. Most value comes from the middle layer, a whole feature rendered with its real children and a faked server, rather than one test per component. What I do not test is internal state, that a helper got called, snapshot files of an entire tree, or styling. Those all break on harmless refactors and pass while something is genuinely broken. Then a small number of end to end tests cover the flows the business cannot afford to break, like signup and checkout, and that is it.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- How do you test a custom hook in isolation?
- Where do you draw the line between an integration test and an end to end test?
- How would you deal with a flaky test that depends on timing?
Related react developer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions