It drives the sample's pass indicator. Our real response contains read status and a separate inspection result, but the mock only supplies success. That distinction never reaches the display test.

Then a successful read and an accepted housing need separate expected outcomes. A valid response containing a reject result should demonstrate that the interface worked while the sample did not pass its defined check.

And a failed read may supply no usable inspection result at all. I would include that beside a valid reject in the examples, so the software is not tested only on two different ways of saying no.

What will the person watching see in those two cases? I mean a rejected sample versus unavailable information, not just whether the developer receives different values.

The decoder tests now distinguish successful reads with accepted and rejected results from failed reads without a result. They caught the original bug: we were treating request success as sample acceptance. The display has separate read and inspection states, though its wording still needs a reader check.

Use the actual display path for that check, including failure after a good result. Otherwise the decoder can be perfectly honest while the screen carries yesterday's accepted housing forward as if the new read supplied it. Keep any history identifiable as history, with the observation it belongs to.

Mei's reader question is useful once those sequences are visible. I would give the reviewer the expected circumstances but not explain the colour scheme first; otherwise you may test their memory of your explanation instead of the screen.

That exposed another ambiguity. Our covering technician read failed as a rejected housing even when the read had failed. We have changed that message to inspection result unavailable and labelled the separate retained value with its sample identity and observation time.

Thanks for posting what they actually understood. That is the difference I was asking about; two internal states would not have helped them while both looked like a bad sample.

The revised display and normal decoder pass the saved accepted, rejected, failed and incomplete-response cases, including failure after success and reopening with history. A reader distinguished current rejection from unavailable inspection information without prompts. Software defect closed; the controller comparison remains explicitly outside this offline result.

Keep those scenario names in the routine test report. They tell the next maintainer much more than mock passed, and they preserve the reason request success stopped being a shortcut to sample acceptance.