HazelAli0223 · 1 Oct 2025, 21:49 UTC
Make unknown calls fail instead of inventing a method for them, and match the documented argument and return shapes at the small interface your application actually uses
11 pointsDoes the screen distinguish no reading from a clear fixture?
21 pointsRick'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.
13 pointsGive failures documented shapes too. Returning false for every failure can hide another parser mistake.
9 pointsToby, would you start with captured replies or the documentation? We have only a few examples on our teaching laptop, all successful.
8 pointsRick, no distinction yet. Programmer is adding explicit unavailable display cases. We have two captured successful replies.
9 pointsOmar, use both, with their source and SDK version identified. Don't call constructed examples captures.
17 pointsCan someone taking over the teaching laptop find which examples are real and which were constructed, without opening every test file?
18 pointsAmara, 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
23 pointsI 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.
17 pointsNarrow API, Rachel, not only one screen state; test the failed and stale cases through that same small interface
8 pointsThanks, Toby. That source label helps. I'd been calling our hand-built examples recordings, which is asking for confusion later.
8 pointsMock now rejects unknown methods and wrong arguments. Unexpected return shapes exercise the parser's unavailable path.
6 pointsWhat does unavailable look like now?
14 pointsAnd 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.
18 pointsRick and Rachel, current status becomes unavailable; details show the last valid reading and its age, when one exists.
19 pointsThat 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.
7 pointsAre delayed replies included, or only immediate returns?
25 pointsToby, 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?
8 pointsDelay cases are next, Toby. Current tests cover calls and parsing only, not the physical fixture or robot.
21 pointsThis discussion is closed to new replies after six months without activity. Last activity: .