Testing at Three Different Boundaries
What is the difference between unit, integration, and end-to-end tests, and when would you use each?
what they're testing: The interviewer is probing whether you can choose a test boundary that gives useful confidence without paying unnecessary setup, runtime, and debugging costs.
The difference is how much of the system each test crosses and which failures it can expose. A unit test keeps the subject small, such as a function or class, and replaces awkward dependencies when isolation matters. It is usually fast and gives a narrow failure signal, but a green unit test says nothing about whether the real database or neighboring service is wired correctly.
An integration test lets selected parts meet for real. An API test that exercises routing, serialization, and a test database checks contracts and configuration that isolated tests cannot. It still need not boot the whole product; the team should name the boundary because "integration test" is used for both narrow and broad scopes.
An end-to-end test drives a complete user workflow through the running stack, such as signing in and completing checkout. That gives strong evidence that the pieces work together, but setup is heavier, runs are slower, and failures have more possible causes. A practical suite balances confidence against cost: many focused tests for logic, integration tests at risky seams, and a smaller set of E2E tests for critical journeys.
Where people slip
the tempting wrong answer, and what's actually true
A unit test must cover exactly one function and mock every other object it touches.
A unit may be a method, class, or small component; the team defines the boundary and isolates dependencies that would widen it.
An integration test has to start the entire application and all of its services.
An integration test can target one interaction, such as an API adapter talking to a database, without exercising a complete workflow.
An end-to-end test should always call real third-party services so the path is truly complete.
End-to-end tests do not have to call live third-party services. Routine suites can cover the workflow through systems you control and replace external calls with controlled responses.
If every unit test passes, the application works as a whole.
Passing unit tests do not verify that components, configuration, and external boundaries work together.
If they push further
What mix of these tests would you put in a CI pipeline?
There is no universal ratio; favor fast, focused tests, then add integration coverage at risky boundaries and E2E coverage for critical user journeys.
Is an API test a unit, integration, or end-to-end test?
Classify it by the boundary it crosses: a handler with isolated dependencies may be a unit test, an API backed by a real database is usually an integration test, and an API test that crosses the whole deployed system may be E2E.
How would you reduce flaky end-to-end tests?
Give each test isolated state and controlled data, avoid uncontrolled third parties, and select elements through user-facing contracts rather than fragile DOM structure.
Sources
- Microsoft Learn: Architecture strategies for testing ↗learn.microsoft.com
- Android Developers: Testing strategies ↗developer.android.com
- Cypress Documentation: Testing Types ↗docs.cypress.io
- Playwright: Best Practices ↗playwright.dev
Now answer it yourself.
Reading a strong answer is easy. Producing one under pressure is the skill the interview tests. Gapmap grades your answer against the same bar an interviewer would.
beta
The interviewer part is in the works.
The diagnostic, personal maps, and AI mock interviews are being finished right now. The notes stay free either way. Leave an email and you'll get the first-cohort invite, plus a month of Pro when it opens.