Make unsupported calls fail clearly, then feed documented success and failure replies through the real adapter. Otherwise a richer-looking substitute can still hide a misspelled method before the parser even sees a response.
Offline UR5e parser tests that cannot fail a bad call
ClaraBrooks0785 · 17 Jun 2026, 19:30 UTC
19 replies
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.
2 pointsI 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.
24 pointsWhat should the screen show before the first successful read?
11 pointsDoes 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.
18 pointsAbigail, that distinction needs to survive export too, if the application saves a report.
11 pointsWe 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.
9 pointsWill a valid inspection failure remain different from failure to obtain any result?
-2 pointsAda'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.
9 pointsAnd 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.
18 pointsThe 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.
7 pointsWho decides the expected result for each test, rather than copying what the current parser already does?
9 pointsThat is worth settling, Beatrice. A test can preserve a bug very diligently when expected output was taken from the first run without review.
15 pointsApplication 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.
12 pointsWill the test inspect the report as well as the screen?
14 pointsIt needs both. Thanks Pavel; fixing only the visible state would leave Clara's collapsed report categories unchanged.
15 pointsBoth 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.
4 pointsHave delayed and out-of-order replies been included yet?
9 pointsNot 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.
11 pointsAdd to the discussion
Welcome to Application Robot
Everyone can read the forum. Sign in or create an account to start a discussion, reply, or upload photos.
By creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.