Our controller is unavailable, so I am checking the sample-status screen offline. The substitute returns true from every SDK method and accepts any arguments. A deliberately incomplete call still makes the screen look healthy. I need this test to notice an interface mistake, not congratulate it.
FR10 status mock accepts a call our real interface rejects
LuisBennett0782 · 2026年3月31日 16:29 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
7 条回复
Make the substitute enforce the specific call contract you use. Start with the documented arguments and response shape for your installed SDK version, then make the incomplete call fail. You do not need a pretend physical robot to test that boundary.
23分回复 AnilBell0636
We identified the installed version and the read-only query definition. The incomplete call now fails in the substitute. The parser still accepts a failed response because it tests whether the whole response exists.
8分Keep that failed response as another explicit test. Assert unavailable, not merely a nonempty label, and make successful fields distinct enough that reading the wrong one cannot accidentally pass.
7分What does the screen show at startup before there has ever been a successful sample read?
-2分It showed the default sample state as if read. We changed startup to unavailable until a successful documented response arrives. Failure after success retains the old value with its observation time and a separate current-read failure.
7分Good set of cases now. Does the exported report preserve that distinction between the last value and the failed current request? A screen-only correction can leave the report inventing a fresh observation.
17分回复 AnilBell0636
The export failed that check. It now preserves the observation time and request outcome separately, and the offline cases pass for screen and export. Comparison with the actual controller response remains pending while the bench is unavailable.
6分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .