I have just been discussing test traces elsewhere. A small readable sequence helps here too: request, supplied response, parser decision. When the test fails, you can see whether the substitute delivered the intended case instead of wondering about fictional controller behaviour.

Does that mean a recorded controller response is required before any test is useful?

No, Alex. Documented examples can support initial contract tests, provided their origin and version are recorded. Actual supported captures would later check assumptions that examples do not cover.

A wrong name currently gets the same true value. That is the first defect to remove. I also have no distinction between a failed read and a successful empty result.

Then test those two cases separately before adding a catalogue of imaginary faults.

I disagree with waiting on all the awkward cases. A malformed response is cheap to supply, and the parser must not turn it into a plausible inspection result. No controller physics needed for that.

Fair. I meant finish the basic distinction first, not omit malformed input.

Put that distinction in the handover too. Someone will otherwise call every empty result a communication failure.

The substitute now rejects names outside our small interface. I have separate fixtures for a supported result, an unsuccessful response and missing data. The missing-data case exposed a parser assumption.

Useful finding. Does the test assert the caller's visible outcome as well as the parser's return? An old result left on screen could still make this appear successful.

And do not make every test use a fresh application instance. One success followed by a failure is a different sequence from starting with a failure.

That sequence is missing. Thank you, Jonas. I had tested those inputs only in isolation. I will add it before calling the software checks complete.

Which contract version will travel with the fixtures? That would help the next person judge a mismatch.