Make that typo fail first, with the substitute exposing only the methods and arguments your actual reporting interface supports
Our UR5e test substitute accepts a method that does not exist
YasminBarnes0528 · 6 Nov 2025, 16:08 UTC
17 replies
Yes. It uses a catch-all at the moment. No method list, no argument checks. The screen test mostly asks whether anything came back.
17 pointsOur interface walkthrough exposed a similar temptation: giving the test information the real application never had. Tie each response example to the interface version you intend to use.
21 pointsWhich reporting behaviour do you want the first replacement to exercise? A small explicit substitute can be useful without modelling every controller function, provided the boundary is clear and unsupported calls fail visibly.
10 pointsPavel, I would start with the one status read feeding that screen, including its failure path, rather than try to build the whole interface before catching this typo
13 pointsAgreed scope: that read only. Saved a valid example with its source version. I've also added deliberate failure and malformed-response cases, labelled as tests rather than captures.
21 pointsCheck what the screen shows after a good reading followed by failure. A substitute can reject the request correctly while the display carries on showing an old value as current. The operator sees the display, not the test result.
23 pointsAnd an initial failure. There may be no old value to display at all.
4 pointsToby, would you also include missing required fields within an otherwise successful response? That tests a different assumption from the explicit failure example Yasmin has already added.
18 pointsYes, alongside unexpected shape; I meant a small set of methods, not a single friendly response for each one
9 pointsThose caught something. The parser rejected a failed response, but the screen kept the green result tile. Now current status becomes unavailable and the previous reading sits in details with its own observation time.
11 pointsDoes that observation time remain unchanged on failed refreshes? A newly updated time beside the previous reading would still imply that it had just been checked.
10 pointsIt was changing. Fixed that in the offline version too. First-failure case has no previous reading. The nonexistent method and wrong arguments now fail instead of finding the catch-all.
9 pointsWhat is your check against the actual interface when it becomes available? These tests establish useful software behaviour, but the saved example alone does not verify every assumption in the replacement.
19 pointsInclude that version check before using it for lessons. The explanation should match the interface learners actually get.
24 pointsWe'll compare the supported calls and returned structures with the installed combination when access returns. Thanks Isabel, the timestamp test earned its place. Offline screen checks pass; interface comparison still open.
11 pointsKeep the typo as a regression test too, an embarrassingly useful little example
9 pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .