How do you decide what to unit test versus integration test, and how do you keep the suite fast and reliable?

role-specific · Mid level · software-engineering

What the interviewer is really asking

Probes practical testing judgment — choosing the right test level for the risk, and keeping a suite trustworthy and fast rather than slow and flaky, which is a mid-level ownership signal.

What to say

• Match the test to the risk: unit-test the logic-heavy, branchy code in isolation (cheap and fast); use integration tests for the seams where your code meets a database, queue, or external API — the places mocks would lie about.
• Attack flakiness at the source: remove real time, network, and randomness from tests (inject a clock, use fakes or testcontainers, seed randomness) so a passing test means the code works, not that you got lucky.
• Keep the suite fast enough to run on every change: lean on a wide base of fast unit tests, reserve the slow end-to-end ones for critical user paths, and quarantine or fix flaky tests immediately instead of letting people learn to ignore red builds.

What to avoid

• Say you chase 100% coverage as the goal, regardless of whether the tests catch real bugs.
• Describe mocking every dependency so 'unit' tests pass while the actual integration is never exercised.
• Treat a flaky test as normal — 'just re-run it' — instead of as a defect to fix.

Example answers

Strong: Our checkout pricing had a dozen discount branches, so I unit-tested those exhaustively with no I/O. But the bug history was all in the Stripe and tax-service calls, so I added integration tests against a sandbox and testcontainers Postgres for exactly those seams. Coverage went where the risk was, not where it was easy.

Weak: I aim for 100% coverage — if every line is covered, the code is well tested.