How should our FR10 fixture-status mock reject a bad call?

Rick's distinction caught us in a screen review. Everything was green because the substitute only knew good news. We needed to see what the operator faced when nothing useful came back, not another successful pretend cycle.

Give failures documented shapes too. Returning false for every failure can hide another parser mistake.

Toby, would you start with captured replies or the documentation? We have only a few examples on our teaching laptop, all successful.

Rick, no distinction yet. Programmer is adding explicit unavailable display cases. We have two captured successful replies.

Omar, use both, with their source and SDK version identified. Don't call constructed examples captures.

Can someone taking over the teaching laptop find which examples are real and which were constructed, without opening every test file?

Amara, put that beside the examples, and keep the mock narrow; building a cheerful substitute for the entire SDK is how you end up back at true for everything

I wouldn't make the screen tests too narrow, though. A stale last-good reading confused our reviewers more than a totally blank startup. Those are two different experiences for the person looking at it.

Narrow API, Rachel, not only one screen state; test the failed and stale cases through that same small interface

Thanks, Toby. That source label helps. I'd been calling our hand-built examples recordings, which is asking for confusion later.

Mock now rejects unknown methods and wrong arguments. Unexpected return shapes exercise the parser's unavailable path.

What does unavailable look like now?

And Hazel, can a reviewer tell whether there has never been a valid reading or the latest request failed after one? That was the awkward bit in ours.

Rick and Rachel, current status becomes unavailable; details show the last valid reading and its age, when one exists.

That sounds easier to hand over than a green state which secretly means yesterday, though I would still show it to somebody who has not helped design it.

Are delayed replies included, or only immediate returns?

Toby, that's the bit I'd struggle with. Our simple mock just answers when called. Would a controlled event queue be appropriate for an asynchronous interface?

Delay cases are next, Toby. Current tests cover calls and parsing only, not the physical fixture or robot.