Our training bench is unavailable, so I tried the fixture-status application with its offline mock. Every method returns true and the coupon screen looks satisfied. I want to test the software calls and response interpretation, not pretend that a successful fake read represents a physical fixture test.
Where does the mock enter the application? It needs the supported method signatures and response contract, with failed and valid-negative examples passing through the normal decoder.
It replaces the client but accepts any method name and arguments. We have replaced that catch-all with the documented interface and replayed recorded response shapes through the decoder. That exposed a misspelled method which the old mock had happily accepted.
Do those tests also assert the visible result after a failed read follows a good one? Correct decoding can still leave a misleading old status onscreen.
Not yet. The current assertions stop at the decoder result, so I cannot call the display handling tested. I've added that transition to the remaining scope along with unavailable data at startup.
Keep both limits in handover: interface and decoder cases checked, display transitions outstanding. Controller behaviour and physical fixture interpretation remain separate bench checks.