Our offline tracker finishes the newer attempt when an older completion arrives late. I want a repeatable event sequence, not another lucky random sleep. The duplicate-result count needs checking too.
Put event delivery under the test's control. Create the two attempts with explicit identities, keep the first result queued, and deliver it only after the second reaches the state you're testing. Assert both attempt states and the report after each delivery, then advance a controlled clock for the timeout cases. Nothing in that sequence needs a physical coupon cycle or a random wait
Before designing the expected answer, check whether the actual completion carries an attempt identifier. If only your test helper knows which attempt it belongs to, you've built a very clever test of an interface you don't have.
Captured events do carry the identifier. Our handler discards it and updates currentAttempt. The harness can feed that captured shape directly, so the missing association is in our code.
I would also send an identity the tracker has never seen. Otherwise a fix can stop stealing a known old result and still attach every unknown event to whatever happens to be active.
And restart while a result is held for review. We once built a careful first recovery page and let the next startup turn the same row back into fresh work. It was a very efficient way of undoing the careful part.
Nina, that restart case should check the report too. Does its processed-result identity survive separately from the screen state? A reopened screen can look right while its summary rebuild counts an old delivery again.
Quality is defining the expected item dispositions with our developer. The controlled old-result sequence reproduces the failure, and we've added unknown identity plus duplicate delivery before and after restart.
Toby's persistence question is the one I'd keep an eye on. Matching an event in memory is the easy half if the same event can be delivered after the process has forgotten it ever existed.
Use the same persisted fixture data across that restart test, not a new empty store that gives every run a clean slate. Then deliver the identical completion again and compare the saved attempt, review entries and accepted-item summary. Keep any authorised retry as a new attempt belonging to the same item, not a second physical coupon
The corrected handler now matches known identities, leaves unknown ones in review and does not change the active attempt for an old result. First duplicate test passes; restart replay still adds a summary count, so we found a second defect.
Does the summary rebuild use event rows or reviewed item state? If it counts delivered rows, persistence alone won't stop repeated observations looking like more coupons.
It used delivered rows. Developer changed the summary to derive from identified items and reviewed disposition, retaining the attempt events separately. Quality's small example now matches after the rebuild.
Ella, I'd want those results, but don't lose the original ordering regression while adding them. A rebuilt count can be right for the sample while a late event still changes the wrong attempt state.
All named cases pass now: old result while new is pending and after it finishes, duplicate before and after restart, unknown identity, and interrupted persistence followed by replay. Both attempt states and quality's item total are asserted. Maintainer accepted this reconciliation fix; no robot motion or inspection capability was tested.