I commented out the controller read while tracing our bracket report and the offline test still passed. The mock supplies true everywhere, then the screen test congratulates it for being true. Not the most demanding colleague.
I want useful tests for the installed read-only interface while the station is unavailable. We have a few captured responses, but no failure examples in the suite. Where would you start before trusting the displayed status or export?
Which boundary are those captured responses from? Feed the fake into the same parsing path as the real interface, otherwise you can test the screen perfectly while bypassing the broken read again.
They are the raw replies our adapter consumes. We replaced the all-true helper with those shapes and added valid unavailable status, read failure and malformed replies. The parser now fails visibly on malformed data instead of treating a nonempty object as success.
What does the operator actually see on a read failure? Our screen once kept the last cheerful status and tucked the error into a log. You could tell something was wrong only if you already knew to look for it.
That's our next failure. The screen changes, but the export keeps the last good status without its age. I've asked the maintainer to make both preserve the read outcome and the time of the last valid observation.
Have you tested recovery after that failed read as well? The corrected export should not remain stuck on an old failure once a genuinely new observation arrives.
Yes. Saved sequences now cover first-read failure, malformed response, valid status, later failure, recovery and reopening. Screen and export agree on current availability and the identity and time of any retained observation. The covering user could distinguish old from current without my commentary. This closes the reporting bug; comparison with the live interface is still on the station's return list.