Staff / expert · Testing and performance
Fault tests around unknown outcomes
How do you test a retry protocol instead of just a retry loop?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
Enumerate failure boundaries: before send, after remote commit, before reply, after local persistence and during shutdown. The same timeout error can correspond to different durable outcomes.
Use a controllable dependency to pause at each boundary, crash/restart the caller and replay the same operation ID. Assert the business invariant, such as one charge, not a specific number of network calls.
Test concurrent duplicates, exhausted budgets and retention expiry. Separate local deterministic tests from integration tests that verify the actual store's atomicity and durability settings. Record what a mock cannot prove.
Common trap
A fake that always fails before committing cannot validate idempotency after an ambiguous timeout.
Try it
Write the invariant for a consumer that may receive an event twice after restart.
Worked solution
For every durable event ID, its business state transition is applied at most once within the chosen authoritative store, while already applied events can be acknowledged again. A transaction/unique constraint must make the claim and mutation atomic.
Change the constraint
Which failure modes would still exist if the side effect is an external email or payment?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.