JackCarter1037 · 12 Sept 2025, 03:02 UTC
Use versioned response examples and enforce the documented arguments. Unknown calls should fail visibly.
10 pointsWe have saved success and failure responses from the installed version, with the method and arguments recorded, so the developer is replacing the catch-all mock with those cases first.
11 pointsDid the invalid argument now fail?
21 pointsTest what the display does after a good response is followed by a failed one. The parser can report failure correctly while the screen still shows the last value as current. Our trainees trust what they can see.
6 pointsAisha, the invalid call fails now; David, your sequence exposed the old value staying current, and the developer is changing that display behaviour rather than replacing the failed response with a convenient default.
18 pointsKeep the last observation time with any historical value. A refresh time beside an old reading can make it appear newly confirmed, even after the colour has changed.
7 pointsAlso try missing data, not only an explicit failure.
10 pointsWhich parts of the new substitute come from saved responses and which are deliberately malformed test cases? I would name that difference so nobody mistakes an invented error case for a controller observation.
2 pointsJonas, captured examples keep their source version and the synthetic malformed cases are labelled separately; failed and missing data now show unavailable, with historical values retaining their observation time, and those offline checks pass, though the real-interface comparison is still waiting for the cell.
10 pointsHas that comparison become possible yet, or is access still pending?
25 pointsThis discussion is closed to new replies after six months without activity. Last activity: .