I'm working on the read-only reporting screen while the controller is unavailable. Every mock method returns true, so all looks cheerful even when the interface handling is wrong. What would make a useful software substitute without pretending it models the physical robot?
Our first substitute copied the happy path and missed the failure shape entirely, so I would base yours on the supported SDK contract and saved responses from that version, with explicit cases for errors and malformed data.
At present it starts at zero and looks like a valid state. I have saved successful and failed responses from our intended version, so I can test more than a boolean without making up a contract.
Keep the first failure separate from failure after a good reading, Chloe, because a retained historical value needs its own age and meaning rather than becoming a fresh observation whenever the screen refreshes.
Sara, that caught a misspelled method in my test adapter. The new cases now reject unsupported calls and keep initial failure unavailable. I've still got stale-data wording to sort out after a good read.
Can someone unfamiliar with the implementation distinguish unavailable now from the last known reading without your explanation? That would tell you whether the wording expresses the state the tests are proving.
Our trainer read the first draft as a current value, so I've separated last observed time from screen refresh time and made current availability explicit. Revised wording review and later comparison with the actual controller are still outstanding.