Weight it by risk rather than by pyramid dogma. Unit tests for pure logic and edge cases, a solid layer of integration tests hitting a real database in a container, and a small number of end to end tests covering the flows that lose money if they break, like signup, checkout and login. Mock third parties at the network boundary rather than stubbing your own modules.
Why interviewers ask this
The interviewer wants to know whether your tests would catch real bugs or just inflate a coverage number. They are listening for integration tests against a real database, because mocking the ORM is the most common way teams write tests that pass while production breaks. They also want to hear how you handle flaky end to end tests, since that is what actually kills a suite over time.
How to structure your answer
- State the principle: test where the risk is.
- Describe each layer and what it is responsible for.
- Explain where you draw the mocking boundary.
- Say how you keep the suite fast and trustworthy.
Example answer
My guiding rule is that a test is worth writing if it would have caught a bug we plausibly ship. Pure logic, pricing rules, date handling, permission checks, gets fast unit tests with the nasty edge cases. The layer I invest most in is integration: real HTTP request into the app, real Postgres in a container, real migrations, assert the response and the resulting rows. That catches the things mocks hide, like a constraint violation or a query that silently returns nothing. Third parties get mocked at the network boundary with something like MSW or a recorded fixture, never by stubbing my own service class, because then I am testing the mock. End to end I keep deliberately small, maybe eight journeys covering signup, login, checkout and the core workflow, running on every merge. Flakiness is the thing I am ruthless about; a test that fails randomly trains people to rerun the pipeline, so I fix it or delete it within a day. Coverage I look at as a diagnostic, never as a target.
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 set up and tear down test data between runs?
- What do you do when an end to end test is flaky?
- How do you test a React component that fetches data?
Related full stack 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