The offline FR5 status lesson looks successful even when I misspell the documented query. Our mock accepts any method and returns true. I want it to enforce the small read-only interface we actually teach, then exercise failure responses. At present the most reliable feature is its approval of mistakes.
Restrict it to the documented method names and argument signatures for the supported version. An unknown method or invalid call should fail the test immediately. Then make the valid calls return version-specific examples rather than a universal boolean.
We have a saved successful response from the intended version. The developer built the mock before that capture existed and never changed its return value. I have asked for the supported interface to be explicit.
Hazel's first-call case is worth keeping. Our old display only handled failure after it had a good value to fall back on. Starting without that value exposed a different problem.
The first failed read should show unavailable with its reason. A previous valid result may remain in a separate last-reading area with its time. Neither should look like a fresh sample status.
Let a tutor see both examples without being told which one failed, because a technically correct label can still be very easy to overlook beside a familiar value.
Yes. The restricted mock now rejects the misspelled method and wrong argument. The saved success parses correctly. Reported failure and malformed-response cases are next; there is no completed display walkthrough yet.
Does your lesson identify that this is an offline response exercise? I would not want a student thinking a convincing screen demonstrates the coupon, fixture or physical robot behaved correctly.
It does. The lesson names calls, responses and display interpretation as its scope. The installed-interface comparison remains separate for when the station is available, and the physical handling exercise is not represented by this mock.