How would you stub a collaborator to reach the branch that only runs when it fails?

### Why the error branch needs a stand-in The happy path can be reached with real collaborators. The failure path usually cannot: a working dependency will not fail to order, and the conditions that make it fail - exhausted balances, rejected writes, invalid states - are exactly the ones that are hard to arrange on demand. So the error handler ships untested more often than any other code in the system, and it is the code that runs when things are already going badly. Stubbing solves this directly. Instead of configuring the stand-in to return a value, configure it to produce the failure: raise the error, or return the rejection result, whichever shape the real collaborator uses at that seam. ### Fidelity is the whole game The test is only as good as the failure it imitates. Three questions decide that: **Is this failure real?** Simulate something the collaborator can actually produce. A debit against a loyalty-points ledger can be rejected for insufficient points, for a closed account, for a duplicate idempotency key. Inventing a failure the ledger never emits produces a handler nobody will ever execute, and worse, it gives the team confidence that the error path is covered. **Is it the right shape?** If the real rejection arrives carrying the shortfall - a request for 1,250 points against a balance of 1,249 - then the simulated one should carry it too, because the handler probably reads it to build the message the member sees. A bare failure with an empty payload lets a handler pass that would break on the real thing. **Is it wrapped the way it arrives here?** Layers often translate errors on the way up. Simulate the failure as it reaches *this* unit, not as it left its origin, or the test proves the handling of an error that never gets to this code in that form. ### Choose the failure modes deliberately A senior answer names which failures matter rather than reaching for one generic error. For a redemption flow the interesting set is small and specific: the balance check rejects, the debit is refused after the check passed (a race), and the debit succeeds but the confirmation write fails, leaving points deducted with nothing recorded. That last one is where the real bugs are, and it is only reachable by making one collaborator succeed and the next one fail. Related, and a classic: an off-by-one on the boundary of the failure condition. If redeeming is allowed only while the remaining balance stays at or above zero, the three cases worth stubbing are a redemption of 1,249, 1,250 and 1,251 against a 1,250-point balance. The middle one is the case a strict comparison gets wrong, and it is the one a single generic failure test never reaches. ### Assert the outcome, never the setup After the stand-in fails, the test must say what the unit should have done about it. Concretely: the call returned a declined outcome rather than propagating a raw error; a compensating entry was written; the reason recorded matches the failure; the member's balance is unchanged. Those are observable facts about the unit. The failure mode to avoid is a test that stubs the error, catches it, and asserts only that an error occurred - which is a restatement of the setup. If the unit is supposed to swallow the failure and return a default, assert the default. If it is supposed to translate the failure, assert the translated type and its contents. ### One failure per test A test that makes every collaborator fail at once cannot tell you which handler ran, and it passes for as long as *any* of them produces the observed outcome. Keep one failure mode per test, name the test after it, and let the set of tests read as a list of the things this unit survives. ### The limits of a simulated failure Be honest about what this technique does not prove. It shows the handler behaves correctly *given* that error. It does not show the collaborator produces that error under the conditions you assume, and a stand-in whose canned failures no longer match what the real thing emits will keep passing while production breaks. That is why simulated-failure tests are paired with a small number of tests that exercise the real collaborator, and why the canned failures deserve a review whenever the collaborator's contract changes.