How do you decide what NOT to test? Explain testing ROI and the 'testing trophy' vs. the pyramid.
Strategic judgment: spending test effort where risk and confidence-per-cost are highest, not chasing coverage.
Mature testing is as much about what you DON'T test as what you do, because every test has ongoing cost (write it, run it, maintain it, debug it when it flakes). ROI = confidence gained per unit of cost, and you want to spend where that ratio is highest. Things generally NOT worth testing directly: (1) third-party code and the framework/language itself — don't test that React renders or that lodash's map works; trust your dependencies and test YOUR usage of them at the boundary. (2) Trivial code with no logic — a getter that returns a field, a component that renders a static string, a config object; a test here just duplicates the code and breaks when it changes, providing near-zero confidence. (3) IMPLEMENTATION DETAILS — private methods, internal state, exact call counts; testing these is negative ROI because they break on refactors without catching real bugs. (4) Purely generated or declarative code, and throwaway/spike code. Conversely, spend heavily where risk × likelihood is high: complex business logic and calculations, edge cases and error handling, code that's changed often or broken before, security-sensitive paths, and the critical user journeys. The 'testing trophy' (Kent C. Dodds) reframes the pyramid for UI-heavy apps: instead of a huge unit base, it FATTENS the INTEGRATION layer (components + hooks + real-ish collaborators) because for front-end apps that's where confidence-per-cost peaks — integration tests exercise realistic behavior without e2e's flakiness/slowness, and 'the more your tests resemble how software is used, the more confidence they give you'. It keeps a static-analysis base (TypeScript, ESLint — free bug-catching before tests even run), some unit tests for pure logic, a strong integration middle, and a few e2e at the top. Pyramid vs. trophy isn't a contradiction so much as a difference in emphasis by app type: backend/library code with lots of pure logic leans pyramid (big unit base); UI apps lean trophy (big integration middle). The unifying principle for an interview: don't chase a coverage number — target the tests that would catch the failures you'd most regret, at the layer that gives realistic confidence per dollar, and consciously skip the low-ROI ones. Contract/consumer-driven tests are the analog at service boundaries: test the interface others depend on, not every internal path.
Prioritizing limited testing time; justifying test strategy in review; pushing back on coverage mandates.
Skip (low ROI) Invest (high ROI)
--------------------------------- ----------------------------------------
framework/3rd-party internals complex business logic & calculations
trivial getters / static markup edge cases, error & boundary handling
private methods / internal state code that changed often / broke before
exact call counts (implementation) critical journeys (login, checkout)
Testing Trophy (UI apps) vs. Pyramid (logic/backend)
e2e (few) E2E (few)
INTEGRATION (most) <- fat Integration (some)
unit (some) Unit (many) <- fat
static (TS/lint) (base)
Aim: max confidence per cost. Don't chase a coverage %.