How do I make our offline status test capable of failing?

We have saved responses and the installed SDK documentation. The mock doesn't match their shapes. It just makes every call look successful.

Then fix that mismatch first. Can you replay a good reply followed by a failure and watch what happens to the old green status?

Imran, did the display show stale data during that?

I've replaced the blanket true with documented response shapes in the test. Good-then-failed leaves our previous status green. Found a real screen bug already.

It did, Nadia, until we separated sample age from the display refresh and moved the logging work; we checked delayed reception separately so a responsive window couldn't fool us again.

Our operator once read 'connected' as 'new result received', which wasn't what that light meant. Will, what does your screen actually call the green indicator?

Will the offline check cover disconnected, waiting and stale states too? Those are the screens someone sees while production is delayed, so they need to make sense without the developer explaining them.

It says healthy. Too broad. We're changing it to separate connection and status freshness, and adding delayed and missing responses to the offline scenarios.

The revised screen now loses its healthy status on failure and shows the last reading with its age. Malformed replies also become unavailable, instead of slipping through as success.

Keep those nasty examples in the tests, they are considerably more useful than a mock that smiles at every mistake you make.

They are retained. This checks our interface handling and display only; the hardware connection still needs checking when the cell is available again.

Have an operator read those offline screens before that next stage. You can settle confusing labels now, while nobody is waiting beside the actual machine.