And test the screen itself. I don't care how correct the decoder is if the last healthy-looking banner stays up after a failed read. That's the bit a person will act on.

Daniel, retaining the previous value can help diagnosis, provided it is visibly previous (not still current).

Display only. I've separated previous from current in the expected results; a failed request must leave current status unavailable. Need the fake to return real-shaped failures now.

Yes, Mei, history isn't the problem. My objection was the healthy banner. Keep the old value if its age and status are clear.

Do not invent a convenient failure shape; use the applicable documented contract and clearly labelled examples, with transport failure and an invalid successful payload as separate cases.

Strict substitute now rejects an unsupported method name. That exposed a typo the old mock accepted. Valid success, reported failure and malformed payload examples are in separate tests.

Who maintains those examples when the supported version changes?

Could you leave their source and version beside them? Future you may be less impressed by today's memory.

Recorded sources and target version with each example. Maintainer owns the set. One test now fails because the screen still gives an unknown value a normal status label.

Keep that failing case. It is exactly the useful disagreement the original substitute couldn't give you. I'd also inspect whether the displayed reason distinguishes unknown payload from a communication failure, so support doesn't inherit one mysterious blank.

Reason is separate in the test expectation, not implemented yet. The unknown payload must never reach the normal label lookup.

Check a valid status whose meaning is negative too; a successful read need not report a favourable fixture condition.

Added that case. The documented negative fixture state remains a valid current reading; failed and malformed reads become unavailable. Parser and screen tests pass after the lookup repair.

And the unsupported-call test still fails the bad call after the repair?

Yes. Re-ran the whole set: bad method rejected, wrong arguments rejected, valid negative state displayed, failed and malformed responses unavailable, previous value marked old. The offline substitute and these application defects are sorted; controller comparison remains future work.

Thanks for listing the cases; that gives the next maintainer something repeatable without borrowing your unavailable cell.