I'm trying to develop our inspection result parsing application offline while the cell is unavailable. It normally uses Fairino FR10 in a fixture inspection station, with a fixture-mounted coupon as a reference.
Our mock returns true for every method, keeping the screen happy without checking the interface properly. I need software response testing, with no claim to physical simulation.
@AnilChan1071 Build only the interface you use, with those response shapes and explicit failures for unknown methods. That'll keep the offline run contained.
Rejecting unknown mock methods doesn't establish that the application stays offline. Another startup path could still create the real controller client.
My containment claim was too broad. Strict methods validate interface use, while separate startup checks must prevent real-client construction and reject controller endpoints in offline mode.
Yes, treat that as an explicit offline failure. It identifies an unsupported method or unwanted application call and should never trigger controller access.
My substitute accepted arbitrary method names. A typo passed every offline run. The fake was exceptionally supportive and entirely useless for that mistake.
Adding a strict interface exposed a stale helper call in our application. It had passed through the permissive mock because unknown calls weren't rejected.
@RachelBaker0522 Our saved examples have the SDK source identifier and matching documentation. I'll keep those attached; loose response files would lose that context.
The scope question is answered: a narrow contract substitute, with successful and failing responses. Readiness still depends on passing those checks and verifying the offline connection boundary.