It even accepts misspelled method names. That explains one suspiciously easy test.

Keep one explicit interface surface and make unsupported calls fail clearly. Your test should notice a method mistake before it gets anywhere near deciding what the response means.

Yes, that needs its own expected state. No invented normal value at startup.

I'd include a good reply followed by a failed one. Otherwise an old displayed value can make a parser failure look like continued success

Unknown methods fail now. I've added captured success and failure shapes with their SDK version.

Are those shapes checked against the documented success condition, or is the replacement mock merely more realistic data for the same truthy-object mistake?

The adapter was accepting nonempty replies. Developer is replacing that with the documented result check.

Thanks for naming the actual bug. More varied mock replies alone wouldn't have fixed it.

Add malformed and unsupported replies too. They should expose uncertainty, not select a default status.

And make the assertions inspect the displayed state, not only the decoder's return. A correct failure value can still leave a reassuring old banner untouched

Good-then-failure now clears the current reading and marks the previous one historical. Malformed-response checks are next.

Keep delayed replies deterministic when you add them. A controlled event sequence is easier to diagnose than a random pause that passes whenever the test feels generous.

Does anyone else depend on this status, or is it display-only?

Display-only in this application. No control decisions. Timing cases aren't implemented yet; this is response testing, not physical validation.

Then report the tested calls and display states, with malformed and timing cases still unfinished.