It does accept arbitrary method names now. I have one captured success and one failure, but need to recover their SDK version before using them as contract examples.

I would keep the captures as evidence while that version is checked, rather than assign them to whichever SDK is currently installed; a real response can still be the wrong reference for the interface you intend to support.

Does the current display distinguish a missing reading from an actual inspection failure? A reassuring default and an invented reject can both mislead the person looking at the result.

Abigail, that distinction needs to survive export too, if the application saves a report.

We have no-current-reading, request failure and valid inspection outcome in the proposed display states. The saved report currently collapses the first two, so that is another place to check.

Will a valid inspection failure remain different from failure to obtain any result?

Ada's question is the important one there. A request can succeed and return a genuine failed inspection; don't make the adapter treat every negative-looking value as unavailable.

And test a good read followed by malformed data, Clara, because a parser can return the correct error while the old display state stays in place and tells the operator something else.

The developer recovered the capture version. We now have explicit method checks and separate request-success and inspection-outcome interpretation in the offline adapter; malformed replies are still to add.

Who decides the expected result for each test, rather than copying what the current parser already does?

That is worth settling, Beatrice. A test can preserve a bug very diligently when expected output was taken from the first run without review.

Application maintainer is checking the cases against the documented interface, and quality is reviewing how valid inspection outcomes appear. We are not using current output as its own authority.

Will the test inspect the report as well as the screen?

It needs both. Thanks Pavel; fixing only the visible state would leave Clara's collapsed report categories unchanged.

Both are in scope. The valid failed-inspection case is now displayed and recorded distinctly from request failure. This establishes those software cases, not the physical inspection's accuracy.

Have delayed and out-of-order replies been included yet?

Not yet, Ada. Malformed and timing cases remain open. We have a bounded set of call and interpretation checks, with those limits written beside the test results.