I've asked about other status consumers before; include any downstream report in the test scope too.

Nothing at all from those cases; the fake approves method names it does not understand, and the caller never receives a realistic unsuccessful response

Start with one known wrong call and one failed response. Write down the expected visible result before changing the fake. Then you can show that the old arrangement misses the mistake and the stricter one exposes it. A large pile of cases is less useful if nobody can explain what the first failing example means.

Use the documented contract to decide that expected result, though. If the test author guesses what a successful payload looks like and the caller author copies the guess, they can agree beautifully while both misunderstand the actual interface.

Keep uncertain contract details marked for later real-interface verification, not converted into convenient fixture values.

Can the displayed reading become old while another request is pending? That state matters to the person watching. I would not want a success-looking screen simply because the most recent attempt has not finished yet.

And test success then failure in the same session. Or success then no new data, which isn't quite the same thing. Fresh starts make stale values rather easy to miss.

Keep the last known value for diagnostics only if its age and status remain clear, because unavailable now is not evidence that the previous reading was false

That is a display decision as well as a parser decision. I would assert the visible current-state result and the retained diagnostic value separately, if both are shown. Otherwise a test can pass because the parser rejected input while the screen still suggests a fresh normal status.

The stricter substitute caught a misspelled call, and our failed-response case now reaches the unavailable display state; the pending-age sequence is still untested

Keep the wrong-call case as a regression check. Fixing the spelling should not tempt someone to restore the permissive substitute later.

Did the test exercise the actual wrapper entry point, or did you call the parser directly? Both can be useful, but only the first checks the connection between caller and interpretation.

Actual wrapper entry point for the failed response, direct caller test for the misspelling; I have recorded that split so the remaining end-to-end display cases are visible

Give the next maintainer a small failing example they can run, with what they should see. A page saying offline tests passed won't tell them whether they accidentally removed the unavailable state while changing the screen.

That should be useful when the cell returns too. The software checks can travel with the real-interface questions instead of being mistaken for proof the physical station is ready.