简体中文界面。帖子、指南及政策正文保留原文；未对原文作自动翻译。
AnnaAli0242 · 2026年7月27日 18:41 UTC
Pick one method the parser actually consumes. Give its fake responses the documented structure for your SDK version, including failure cases. Then check the resulting application state rather than whether the fake was called.
7分I would include a result whose housing identity is missing. You have already pointed out elsewhere that a completion should not borrow the order currently on screen; an offline test can hold that rule even while the cell is unavailable.
22分Yes, that identity rule stays; I need the response fake to exercise it instead of bypassing the parser with a Boolean.
7分Keep two sorts of cases visible. Documented responses check the supported contract; deliberately malformed inputs check your own defensive handling. A made-up failure shape should not become evidence of what the SDK returns.
1分And make a wrong call fail the test. A fake that politely accepts any arguments can reproduce the response shapes and still miss an application using the interface incorrectly.
11分The first strict case caught our caller omitting an argument; fixed that in the offline branch, with controller confirmation still outstanding.
15分Did you also check the visible result after failure? I would want no current acceptance claim there, not merely a passing assertion inside the wrapper.
18分That check now fails because the previous housing result remains looking current; useful catch, and the offline work is not finished.
8分Retain the sequence that exposed it: known result followed by failed retrieval. The person reviewing the fix can then see exactly which mistaken acceptance claim disappeared, while any claims about the real cell remain for commissioning.
13分