简体中文界面。帖子、指南及政策正文保留原文;未对原文作自动翻译。

Our UR5e test substitute accepts a method that does not exist

YasminBarnes0528 · 2025年11月6日 16:08 UTC

已关闭
YA
YasminBarnes0528
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?

17 条回复

TO
TobyAllen0318

Make that typo fail first, with the substitute exposing only the methods and arguments your actual reporting interface supports

11
YA
YasminBarnes0528

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
IM
ImranAdams0131

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
PA
PavelCarter0962

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
TO
TobyAllen0318

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
YA
YasminBarnes0528

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
IS
IsabelChen1170

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
IM
ImranAdams0131

And an initial failure. There may be no old value to display at all.

4
PA
PavelCarter0962

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
TO
TobyAllen0318

Yes, alongside unexpected shape; I meant a small set of methods, not a single friendly response for each one

9
YA
YasminBarnes0528

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
IS
IsabelChen1170

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
YA
YasminBarnes0528

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
PA
PavelCarter0962

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
IM
ImranAdams0131

Include that version check before using it for lessons. The explanation should match the interface learners actually get.

24
YA
YasminBarnes0528

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
TO
TobyAllen0318

Keep the typo as a regression test too, an embarrassingly useful little example

9

讨论已关闭

此讨论已连续六个月没有活动,现已关闭新回复。 最后活动: .