The mock behind our sample display returns true for everything, so of course the screen looks healthy while the controller is away. A saved failed read has a completely different shape and our parser doesn't even get through it.
I'd like to use captured responses properly. What would make a small offline test set useful without building a pretend controller around it?
Start with that failed read and a matching successful one. Same SDK version and method. Does the screen show failure clearly, or does the parser exception leave the old value there?
Our test fixture once reshaped all saved responses into a common format before handing them to the parser. Very tidy, and it removed the exact awkward response we wanted to test. I'd keep your captures as they arrived, with notes beside them instead
Luca, I've added last successful read time to the proposed display change. Pavel, keeping the raw captures separately; the test will feed them into the same parsing entry point as the real read.
Include the documented failure forms as well as the captures you happen to have. I would label their source and version separately, because an example constructed from documentation is useful but is not an observed controller response.
Yes. Failed and malformed test responses now show unavailable, with any retained value clearly marked last known and its original read time unchanged. I also found one consumer treating a nonempty failure response as true, which the old mock had rather helpfully concealed.