Our offline controller-reporting screen works because the mock returns true to everything. I need the developer to test the response interpretation, including missing data, while the FR10 bench is unavailable. The bracket shown on screen must not become rejected merely because its status could not be read.
Use saved responses from the applicable interface and send them through the real parser. Start with a successful read, missing data and a failed read rather than a mock-only screen path.
The developer has saved successful and failed reads from the same application version. We can also supply a deliberately incomplete response. The current mock was bypassing the parser entirely.
Keep response failure distinct from the controller status being reported. I would want the screen to say that the read failed, with any older value clearly identified as old.
Robin, it keeps the old value looking current. The success-to-failure test exposed that immediately. The developer has separated last successful value from current read state in the draft.
Yes, and the diagnostic says which required field was absent. First-read failure shows no value. A later failure shows the last reading as old, with its observation time, not as a new reading.
Have the trainer read both screen states without the developer explaining them. The distinction may be correct internally while the wording still suggests an inspection rejection.
The trainer recognised both as unavailable current status, not rejected brackets. Saved success, failed read, incomplete response and success-then-failure all passed through the real reporting screen. This offline repair is complete; controller connection checks remain separate.