CalebCarter1015 · 5 Feb 2026, 00:49 UTC
Limit the substitute to the methods your supported reporting interface actually exposes. It should reject the nonsense name, not provide a default response for any name.
6 pointsDone. It now catches the invented name and wrong argument count. Less agreeable already.
13 pointsWhat does your application do with a genuine failure response? A strict method list helps, but always returning the same successful value could still leave the display's error handling completely untested.
13 pointsWho is supplying the representative responses for that supported version?
6 pointsOur developer has retained responses from the supported read-only interface, Jack. Anil, the display currently leaves the last good state showing after a failed read. No indication it stopped receiving valid data.
8 pointsTest that sequence explicitly. A good result followed by failure should not look like a fresh good result; include a later valid response to check recovery as well.
18 pointsThe test now exposes the stale display. Developer is adding an unavailable state and last-success indication. I've kept the failing sequence in the handover tests; the display change isn't finished yet.
21 pointsAsk the person reading it whether the last-success indication is clear once that change is ready. A timestamp can be technically present and still look like the time of the current result.
11 pointsThis discussion is closed to new replies after six months without activity. Last activity: .