I have an offline FR5 fixture-status exercise for an inspection block. The training controller isn't available. My mock returns successful values everywhere, so the parser looks dependable without meeting a difficult response. I need a more honest software handover; this isn't a simulation of the physical fixture.
Start with the decisions your screen makes. If it displays a confirmed fixture state, which parsed information justifies that display? Then make a fake response where that information is absent or unusable and see whether the screen still says confirmed. You don't need to invent a complete controller to find that kind of mistake.
I found one. A failed read after a successful one leaves the previous confirmation visible without marking it old. The parser returns failure, but the screen keeps the last good value. That is in our application, not evidence about an FR5 response.
Then keep both cases in the test: failed first read and success followed by failure. I have seen the first one handled neatly while the second inherited a reassuring old result. Will the exercise user be able to tell old data from a fresh confirmation without opening a diagnostic log?
Yes. The display now says unavailable after a failed read and shows the previous value separately as historical. I added assertions for both sequences, plus recovery to a new successful read. Those pass in the offline exercise.
The handover now includes those test responses and the display checks. Thanks, Leo; looking at the decision on screen found more than adding another happy response would have. Controller compatibility and physical fixture behaviour are explicitly outside this exercise.