An old completion finishes my newer coupon attempt if I delay it until the newer one starts, but random sleeps make the test wonderfully good at passing when I want to show someone the bug; how do I make the delivery order repeatable offline?
Give the test control of when each saved event is delivered. We caught a similar handler mistake by starting two attempts and releasing the older result deliberately, not waiting for a lucky delay. Assert which attempt changed, not just that the completed total looks plausible.
I would test those separately. A correct saved row with a misleading display can still send the wrong coupon onward, although it needs a different fix.
Keep the earlier attempt in the expected output too. It is easy to say the new one must stay unfinished and forget to say where the old result belongs.
Anna, would an earlier result still be useful if that attempt was abandoned? I wouldn't want the operator seeing an old green result beside the new work and thinking the coupon had passed.
Nora, the event can remain attached to the abandoned attempt without accepting the current coupon. Its disposition needs to be explicit in the test. What state was Leah's earlier attempt in?
The earlier attempt was superseded, so its delayed result belongs in that history and must not accept the current attempt; I have made that the first expected case.
Bruno's direct handler test is a good starting point. I'd still send the same sequence through the application's event entry point afterwards. Ours had a second lookup there which quietly stripped away the identity the corrected handler needed.
The direct case now fails consistently on the old handler and passes with lookup by full attempt identity; the event-entry test is next, without random sleeps.
Use the same event identity for that duplicate. Then make a separate case for a different result event claiming the same attempt, since conflicting information should not be hidden as a harmless repeat.
Martin, agreed, but keep the simple duplicate case readable. A failing test shouldn't require someone to understand the entire inspection application before they see what was counted twice.
Duplicate delivery leaves one historical result, and a conflicting result is flagged without replacing it; both cases pass through the application entry point now.
Current attempt stays waiting, then completes only when its own matching result arrives; closing and reopening between the old deliveries preserves those states too.
Thanks for explaining the superseded result, Sofia. I can see why deleting it would lose useful history, but showing it as the current answer would be worse.
Those are useful repeatable checks to hand over. Keep the saved rows and screen expectations with the sequences so a future display change cannot undo the distinction while the handler tests remain green.