SarahBrooks0850 · 18 Sept 2025, 06:24 UTC
Use a queued sequence where the test explicitly releases each event, asserting the state after every delivery; keep the old result waiting while the new attempt begins, then deliver it on command.
14 pointsWe have that sequence now and it reproduces the wrong match every time; both attempts currently share the plate label, with no separate attempt identity.
11 pointsAdd the same old result twice. One delayed nuisance is useful; two will catch a fix that only throws away the first one.
21 pointsAlso keep the old attempt in the test history. Or rather, don't make success mean forgetting its result entirely. It should find its own attempt without changing the newer one.
-3 pointsJulia, duplicate added; Owen, agreed, the expected result updates the earlier attempt once and leaves the newer attempt waiting, with unmatched results kept separate.
19 pointsDoes the proposed attempt identity remain unique after restarting either side of the interface, not only while the test process stays open?
8 pointsNot in the first draft, Sarah Brown; the counter reset on application launch, so we've added that restart sequence before the developer changes the matching code.
8 pointsGood catch. Test restoring an older saved file too, if that's something your maintainer actually does. Reopening isn't the only way old numbers come back.
19 pointsHave the revised identity and duplicate cases passed now, or is the restart behaviour still being redesigned?
16 pointsThe revised offline cases pass, including the older-file restore; thank you both, those were missing from my original happy-path test, but controls still needs to verify the real interface carries and retains the agreed identity.
17 pointsHas controls completed that interface check? I'd keep the offline result separate from the installed-system result in the handover until then.
19 pointsThis discussion is closed to new replies after six months without activity. Last activity: .