Found a typo in our read-only reporting code. Offline tests still pass. The substitute accepts any method name and hands back true, so I've apparently built a very agreeable piece of test kit. What should I replace first while the controller is unavailable?
Our UR5e test substitute accepts a method that does not exist
YasminBarnes0528 · 2025年11月6日 16:08 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
17 条回复
Make that typo fail first, with the substitute exposing only the methods and arguments your actual reporting interface supports
11分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分Our 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分Which 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分Pavel, 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分Agreed 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分Check 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分And an initial failure. There may be no old value to display at all.
4分Toby, 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分Yes, alongside unexpected shape; I meant a small set of methods, not a single friendly response for each one
9分Those 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分Does 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分It 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分What 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分Include that version check before using it for lessons. The explanation should match the interface learners actually get.
24分We'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分Keep the typo as a regression test too, an embarrassingly useful little example
9分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .