How do you decide what to cover with unit tests versus integration tests versus end-to-end tests in a frontend app, and how do you keep the suite from becoming slow and flaky?
technical-conceptual · Mid level · software-engineering
What the interviewer is really asking
Assesses a deliberate frontend testing strategy — the right test at the right level, with attention to confidence vs. speed and flakiness.
What to say
- Describe the shape you aim for: many fast unit tests for pure logic and hooks, a solid layer of integration/component tests that render real components and assert on user-visible behavior, and a thin layer of end-to-end tests for the few critical user journeys.
- Explain you test behavior, not implementation — query by role/text and simulate real user interactions (Testing Library philosophy) so a refactor that keeps behavior doesn't break the test.
- Address flakiness directly: avoid fixed timeouts in favor of waiting on conditions, isolate tests from shared state, mock or stub the network deterministically, and keep slow real-browser E2E runs scoped to high-value paths.
What to avoid
- Defaulting to 'we should have 100% coverage' as a strategy — coverage is a number, not confidence, and high coverage of trivial code is wasted effort.
- Pushing everything into E2E because 'it tests like a real user' — slow, flaky, and expensive to maintain at volume.
- Asserting on internal state or snapshot blobs so every minor refactor breaks tests, which trains the team to ignore failures.
Example answers
Strong: I aim for lots of fast unit tests on logic and hooks, a meaty middle of component/integration tests that render the component and assert on what the user sees, and a thin set of E2E tests over the few journeys we can't afford to break, like checkout. I test behavior over implementation — query by role and simulate clicks — so refactors don't cause false failures. For flakiness I wait on conditions instead of arbitrary timeouts, reset shared state between tests, and stub the network deterministically.
Weak: I write a test for every function and try to hit 100% coverage. For the important stuff I use end-to-end tests with the real browser because that's closest to how users actually use it, and if a test is flaky I just re-run it in CI until it passes.