A mock that even passes a misspelled status call

The developer can restrict the method names. I'm keeping the typo as a test. What should the valid method return, though: our saved replies or something smaller?

We found a parser that accepted any nonempty reply. Small made-up happy replies would have missed it. Use your version-linked examples for the shapes you actually handle, then add explicit failures and unexpected shapes.

Could the saved replies contain somebody's part identifiers? I mean before they go into a shared teaching folder.

Yes, worth checking. Keep the structure and the relationships needed by the test, but don't carry unrelated production details into the teaching material.

They're local maintenance examples, but Omar is right, one includes a job description we don't need. The developer will prepare reviewed fixtures from them. The raw originals stay separately with their version notes.

A passing parser test still doesn't tell you whether the operator reads the screen correctly.

Naomi, especially after a good reading followed by a failed one. I've seen the old number keep winning because it was large and green while the failure message was tucked underneath.

Would you remove the old number altogether, Felix? I can see why keeping it could confuse people.

Not necessarily. Last known can be useful. Just stop presenting it as current, and show how old it is. I don't want a big reassuring number with a tiny technical excuse attached.

The first failing-response test caught exactly that: our screen retained green styling from the previous success. The parser returned failure correctly. We would have missed it by testing the parser alone.

That's a useful split in the tests. Check the parsed state, then the displayed state after a sequence of reads. Keep the first-read failure too, when there isn't any earlier number to fall back on.

Now tested: unknown method, wrong argument, unexpected response shape, first failure, and good then failed. They fail or display unavailable as intended. Old values are labelled and aged separately. These are offline checks; the installed interface comparison still has to happen.

Thanks for listing them. Did you include an old response arriving after a newer one?

And get someone from the actual shift to read that revised display. Our idea of obvious can be surprisingly generous to our own work.

Mina, keep Omar's late-response question open if it isn't in the test set yet.