The test currently asserts only a successful call. It doesn't inspect the parsed fixture status.

Then a realistic mock alone won't fix that assertion; your test needs an expected interpreted value and a meaningful failure when the parser produces something else.

Start with a tiny set of documented cases. One successful response and one failed request can tell you a lot before anybody spends a week building simulated machinery you do not need.

Keep each example's source and supported version with the tests, since an old capture can accurately represent a contract the replacement installation no longer uses.

Does anything else consume this interpreted status, or is it only displayed?

Henry's question affects how widely the fix needs checking; don't assume a screen-only bug if another application reads the same wrapper result.

Display-only here. The first explicit assertion exposed our wrapper's default available value when interpretation fails.

Treat unavailable data as unavailable, rather than swap the default for another normal state. Also exercise malformed replies separately from a documented request failure.

Try a valid reading followed by a failure. The new result can be handled correctly while the display quietly keeps yesterday's reassuring text.

And test a wrong argument at the boundary. If the substitute ignores it, a broken application call can still pass every response example you added.

Those cases are in. Failed and malformed replies no longer appear as current readings; invalid calls fail the boundary test.

Who owns the real-controller comparison when the station becomes available, so these software results do not silently become the whole release decision?

Software maintainer owns it. Thanks, the pending hardware comparison is now on the handover alongside these offline cases.

Keep that comparison read-only and within the approved setup. The substitute checks declared interface behaviour; it establishes nothing about physical handling or the cell's safety functions.