How do I make our FR10 parsing mock capable of disappointing me?

Harriet_Bailey · 16 Aug 2025, 16:31 UTC

Closed
HA
Harriet_Bailey
I unplugged the idea of a controller from our tests and everything stayed green. The substitute returns true for every method, so a misspelled argument and a failed inspection reply apparently deserve the same congratulations. The bench is unavailable. What response cases should I agree with our software maintainer before using this mock for the display handover?

4 replies

YA
YasminAdams0093
Replying to Harriet_Bailey

Ask for examples tied to the supported SDK interface, including successful results, reported failures and malformed replies, and check what the display should show for each rather than only whether the test finishes.

24 points
HA
Harriet_Bailey
Replying to YasminAdams0093

Maintainer has supplied documented response examples and the expected call arguments. First failure case exposed a leftover result staying on screen as current. So at least the mock is less agreeable now.

7 points
YA
YasminAdams0093
Replying to Harriet_Bailey

Did the display change cover an unavailable result as well as an explicit failure? I would be interested how the handover distinguishes those from a valid inspection result.

24 points
WI
WillCarter1009
Replying to Harriet_Bailey

Also make an unexpected call fail visibly in the test. Returning a plausible result from any method name can hide the same interface mistake all over again.

-3 points

Discussion closed

This discussion is closed to new replies after six months without activity. Last activity: .