I renamed the read-only status method in our offline UR5e report test and it still returned success. The fake interface accepts everything. Handy colleague, terrible witness.
I'm looking after the test environment, not claiming to simulate the cell. What should the developer make strict first?
Which report result are you actually checking? If it's only 'window opened', tightening the fake call won't tell you whether the parser used the response.
I would include the failure display from the start. People need to recognise that there is no current reading, rather than be comforted by whatever number the page had lying around.
Aaron, only page creation at present. Luis, developer has identified the versioned read contract. David, the page currently uses the same green label for the substitute's true and an actual parsed status.
Priya's check would be useful. Add a documented failure response beside it, rather than building a large fake interface before one read is tested properly.
And keep the test's own result separate from the reported controller status. I once read a big PASS as the sample outcome. Turned out it meant the test runner had finished.
That confusion was possible on ours too, Aaron. Test-run results now sit outside the sample report. The strict fake rejects unknown calls and the parser tests check displayed values, failures and malformed replies.
What happens after a good reading followed by a failed one? The operator should not need to infer age from the fact that the number looks suspiciously steady.
Both now pass offline. Initial failure shows unavailable; a previous good reading keeps its time and source without claiming to be current. The real-interface comparison is assigned to our technician but hasn't happened yet.
Keep that remaining comparison with the version record, so the next environment rebuild starts from an identified test boundary rather than another universal true