I'm developing read-only FR10 reporting while the maintenance cell is unavailable. Our mock returns true from every call and keeps the screen happy without checking the interface. I have documented status queries, not a physical simulator. What should a useful substitute and its tests actually cover?
Replace unconditional truth with the supported SDK's documented response shapes and failure behaviour, then assert the parser's actual fields rather than only successful screen startup.
It checks that the wrapper returned something and the screen opened. The status field isn't asserted at all. So yes, the test could pass with the interpretation wrong.
Can you start with one documented successful response and one failed request before building a huge substitute? Those two should already expose whether the screen distinguishes a reading from no reading.
And use the same application parser in the tests; don't accidentally write a second interpretation inside the mock and congratulate that one for matching itself.
Let a tutor see the failed-request display once that works. Software assertions can confirm the state while the wording still encourages someone to trust yesterday's value.
Where will the software-only limit be recorded for the eventual handover? A polished offline demonstration must not become evidence that the robot, tooling or safety functions have been exercised.
Jess, I'd keep that limit in the test scope and handover. I don't think Noah needs to simulate physical motion at all for these read-only contract checks.
Agreed. Scope is response interpretation only. I've added field assertions and invalid-argument cases using the real parser; it exposed a wrapper fallback that replaced missing data with available.
Test a good reading followed by that missing-data response too. Does the display explicitly age or invalidate the previous value when it cannot obtain a new one?
Include malformed structure separately from a documented unsuccessful request, since the diagnostics should tell maintenance whether interpretation failed or the request returned a failure.
Software maintainer owns them. Good-then-failed now marks the old value as previous, not current. Thanks Luca Brown, the tutor said the original wording still looked like a live reading.
Will you compare one documented read with the real controller when the station returns? That checks the boundary you've modelled against the supported setup.
Yes, that is a separate pending verification. Offline success, failure, malformed reply and stale-display cases pass now; the cell is still unavailable, so no real comparison claimed.
Keep that pending comparison attached to release planning. The useful result here is software behaviour under declared cases, and it should remain that specific when the bench demonstration is shown to others.