Our offline acceptance test occasionally lets an old plate result finish the newer attempt. The random delay makes it fail only sometimes, so the programmer cannot tell whether a change fixes anything. What event sequence should the test control explicitly?
Hold the older completion, establish the newer attempt, then release the old event at a defined point. Assert that the new attempt remains incomplete and that the old result is handled under its own identity, with the expected outcome clearly stated.
We can queue the completion in the fake transport. The current handler reads the selected attempt rather than the event identity, which explains why the delay changes the result.
Then put the check at the state change, not only on arrival at the fake transport. Otherwise your test can prove the event has the right ID and still let the handler ignore it.
Pavel, agreed. Anika, keep repeated delivery of the current completion as a separate case too. Correctly rejecting an older attempt does not necessarily stop the same valid result being counted twice.
The delayed-old-result test is repeatable now and fails on the original handler. The revised handler leaves the new attempt unfinished. Duplicate current result still adds a second count, so that is a separate failing test.
Good, two named problems instead of one flaky failure. Keep the duplicate test red until the stored bookkeeping handles it, rather than hiding the extra count only in the display.
The storage fix is proposed, not tested yet. Thanks Ada for the controlled sequence and Pavel for checking where the assertion belongs; the delayed case no longer depends on how busy the laptop feels.