Our UR5e bench is unavailable and the fixture-status mock returns true for everything, so I can make the coupon screen look reassuring without knowing whether it has understood a response or even asked about the right fixture, which leaves whoever takes over the bench with a rather expensive guessing exercise; how would you make the software test useful without pretending it simulates the hardware?
What does the application actually receive at its interface boundary? A Boolean mock cannot test a parser expecting a structured response, even if the screen accepts both.
The adapter should return a read outcome plus a fixture identifier and observed state, but our mock skips that adapter and returns true straight to the screen, so the decoder isn't involved at all.
Ella, it displays the selected fixture, not the identifier returned with the observation, and Emma, replaying an old response for fixture A while B is selected still colours B as ready; I've reproduced that without a controller.
That suggests a correlation failure as well as the untested decoder. Does selecting B invalidate A's pending request, or merely change the visible label?
Leo's point matters at handover. The selected fixture should remain the operator's selection. An older observation can belong in history, with its identity, but it must not silently take over the current task. Keep the cancellation or invalidation rule visible in the software contract so the next developer doesn't restore the behaviour while tidying the screen.
I'd keep that old observation out of the main result altogether. History is useful, but two fixture names beside one status invites another misreading.
Harish, selection only changed the label, and we've now changed the request handling to bind each response to its fixture and request identity, while the decoder tests use the documented response shapes rather than my old shortcut; a failed read now has no fixture-ready result to paint.
That sequence exposed a second check which still compared only fixture names, thanks Harish, and after fixing it the delayed first-A response stays in history while the current request remains pending; valid ready, valid not-ready and failed-read examples also take separate paths through the real decoder.
Keep the delayed-response test with the handover build. Controller reconnection and physical fixture behaviour remain bench work; the software result here is precise enough to retain without claiming either.