The Runtime Theory
mediumApplicationInternals#explain-the-model#reason-about-tradeoffs

Explain Choose Tests by the Failure They Can Catch

Explain the model, execution steps, complexity, and limits of choose tests by the failure they can catch.

TRT practice prompt — not a verified question from a named employer.

The Runtime Theory Team6 min read

Interview prompt

Explain choose tests by the failure they can catch to an engineer who understands the surrounding system but has not used this technique. Walk from its contract to a concrete operation, then discuss where it fails or becomes expensive.

A strong answer

Tests provide evidence about behavior at different boundaries. Unit tests isolate a small decision; integration tests exercise collaboration between components; end-to-end tests validate a user-visible path. Each level trades feedback speed, realism, and setup cost differently.

A unit test can verify that a retry policy stops after its configured budget. An integration test can verify that the persistence adapter records an idempotency key. An end-to-end test can prove the checkout flow returns the expected result through the deployed browser-facing path.

A complete answer also calls out the assumptions that control correctness. High coverage does not prove meaningful behavior was asserted. Tests that duplicate implementation details can block harmless refactoring, while a few end-to-end tests may miss many edge cases. Choose representative contracts and include failure and boundary conditions.

Close by describing one representative test or measurement. A service test passes with a mocked database but production loses updates under concurrent requests. Which test layer was missing, and what invariant should the new test exercise?

Follow-up questions

Answer the follow-ups in the frontmatter. Use the linked article for the concept and the trace to make the explanation concrete.

This answer walks

Practice follow-ups

  1. 01Which assumption is essential for the approach to be correct?
  2. 02What is the worst case, and how does it change the resource cost?
  3. 03How would you adapt the design if the input or workload became much larger?
  4. 04What boundary test would give you the most confidence in the implementation?

One dispatch a week

The trace behind each question, the tradeoff that explains it, and one technical dispatch per week — no noise.

One technical dispatch per week. No noise.

Not started

Sign in to save your learning progress.

Sign in to save