An old completion can finish the NEW inspection attempt in our offline FR5 test. I can make it happen by delaying a message, but not reliably with the sleeps I've scattered about.
I want a repeatable sequence: start A, start B, deliver A's result late, then deliver it again. What's the cleanest way to control delivery without turning the test into a second broken version of the application?
Put a queue at the test delivery boundary. Enqueue named events, release them explicitly in the order you want. The application should still use its normal handler; don't recreate the reconciliation logic inside the test.
Our fixture messages carry an attempt identifier. I'm checking that against the real recorded interface before I trust the test. Omar, explicit release is what I was missing.
Got the bad sequence repeatable without a single sleep. It fails on delivery of A, exactly where it should. Weirdly satisfying to have a reliably broken test.
That is useful. Keep that sequence as a named case, including the expected state of both attempts. Someone diagnosing a later regression should not need to rediscover the timing trick from a pile of unexplained messages.
Not signed off yet. The revised offline handler leaves B pending when A arrives and ignores the repeated delivery for counting. Real-message mapping is still with the interface owner.
Thanks for coming back with that distinction. I would keep the test result and the interface check as separate handover entries until both are complete.