Our offline stand-in returns true, so the inspection screen stays green even when I give it no coupon result at all; with the UR5e bench unavailable, I want to replace that cheerful nonsense with saved application responses, but I don't know which examples would expose a bad parser instead of merely keeping the demonstration running
Have you got a saved failure response as well as a success, because I would start by making the screen tell those apart before collecting a museum of edge cases
Yes, an accepted coupon and a rejected coupon from the same application version; the programmer says the stand-in bypasses the parsing code, which explains a lot
Our packing demo once showed the result of the previous carton, so does your rejected response actually change the displayed coupon identity as well as the colour?
The saved reject exposed it: our wrapper tests whether the response has contents, then treats that as acceptance, without reading the result field; the reject response has contents too, obviously
It reports an unreadable result and leaves acceptance unset; the programmer added a test with an unrecognised value as well as the captured accept and reject, but has not checked the display identity yet
We added reject_after_accept, empty_response and reopen_without_result to the application tests, plus a response for the wrong coupon; the first three now pass, but the wrong-coupon case revealed that the heading changes before the old result is removed
The export already used the response's coupon identity correctly; we fixed the display reset and the wrong-coupon test now leaves the selected coupon pending, with the other response listed against its own identity, and all five saved-response cases pass through the normal parser and screen code