Testing Strategy & Pyramid Interview Questions
TESTING › Strategy
How do you decide, for a new feature, which parts get unit tests, which get integration tests, and which get UI or end-to-end tests?
What a strong answer covers: Prioritize by risk and cost: business logic and edge cases go into fast unit tests since they're cheap to write and run, boundaries between real components (a repository against a real local database, or a use case composing several collaborators) get a smaller number of integration tests to verify the contract actually holds, and slow, flaky-prone UI or end-to-end tests are reserved for a handful of critical golden paths. The mistake is testing everything at every layer, which burns CI time without adding proportional confidence.
Your team has 80% code coverage but keeps shipping regressions. How would you investigate why, rather than just writing more tests?
What a strong answer covers: Look at what the covered lines are actually asserting; a lot of coverage often comes from tests that just exercise a code path without asserting meaningful output values, or from trivial getters and happy-path-only tests that never hit edge cases. Also check whether the pyramid is inverted, with heavy UI test coverage and thin coverage of the business logic layer where real bugs live, and target fixes at the layer a recent regression would actually have been caught at instead of chasing the coverage number itself.
When is it actually the right call to skip automated tests for a piece of code, and how would you defend that in a design doc?
What a strong answer covers: Trivial glue code with no branching, throwaway or soon-to-be-removed feature-flagged code, and properties already guaranteed by the type system or a linter are reasonable candidates to skip. The defense isn't just 'it's simple'; it's naming the alternative safety net you're relying on instead, such as code review, a staged rollout, or production monitoring and alerting, so the decision reads as a deliberate trade-off rather than an omission.