Testing the uncomfortable path.

Follow the failure through

I would choose tests based on what could make the workflow hard to recover. A missing response, a partial write, or an expired credential can reveal more about the operating design than another example of the expected path. The useful question is what the person running the system will see next.

I want to check that the failure is visible, the earlier work remains understandable, and recovery does not repeat an action unexpectedly. Testing these paths also improves documentation because it replaces an imagined recovery procedure with a sequence someone has actually exercised.