The cell is unavailable, so I'm testing fixture-status interpretation offline; our fake SDK says true to everything and makes the screen look fine, which tells me very little about whether we've used the interface correctly
What does the real documented call return on success and failure? I'd start there and make the fake strict about the methods and arguments your application uses, because a boolean that blesses every call can hide a typo as happily as a missing payload. Run the real parser against those version-linked examples, not a second pretend parser inside the mock.
Our documented success has status plus data; failure has no usable fixture state. Developer found the screen adapter turns missing data into zero, then labels that as a real state
That is a specific failure to retain in the tests. What does the screen do after one valid observation followed by failure, as well as on the very first failed read? A held old value and a fabricated zero are different misleading displays.
Old value stays looking current after a later failure. Developer has split current, stale and unavailable in the test build, with last-success time shown only when there was one
Can you make the strict fake reject unknown calls and malformed return shapes too, Nina? The status-display fix is useful, but your original question included catching interface mistakes, not only making documented failures look honest.
Those checks pass now, along with first failure, success then failure and recovery to a new success; wrong signatures fail explicitly and unexpected replies stay unavailable. Maintainer accepted the parser and display fix from these offline cases, with real-interface verification still required when the cell returns