I'm developing inspection-result parsing while our FR10 cell is unavailable; my fake returns true for everything, which keeps the housing screen cheerful but tells me nothing about response handling (software testing only, not a motion simulation).
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.
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.
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.
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.
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.
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.