Where should a software mock stop? (Universal Robots UR5e, fixture status interpretation)

ElenaBarnes0601 · 1 Sept 2026, 04:09 UTC

Reply to discussion
EL
ElenaBarnes0601
I'm trying to develop our fixture status interpretation application offline while the cell is unavailable. It normally uses Universal Robots UR5e in a fixture inspection station, with an inspection block as a reference. Our mock returns true for every method, keeping the screen happy without checking the interface properly. I need software response testing, with no claim to physical simulation.

18 replies

ME
MeiChan1125
Replying to ElenaBarnes0601

Do you've captured success and error responses tied to the documentation for the SDK your screen uses? Those would give the substitute concrete contracts to follow.

21 points
EL
ElenaBarnes0601
Replying to MeiChan1125

Yes. Replaying our saved error response reproduces a parser bug. The always-true mock sailed straight past it, naturally.

15 points
ME
MeiChan1125
Replying to ElenaBarnes0601

@ElenaBarnes0601 Build only the interface you use, with those response shapes and explicit failures for unknown methods. That'll keep the offline run contained.

7 points
CH
ChenAdams0094
Replying to MeiChan1125

Rejecting unknown mock methods doesn't establish that the application stays offline. Another startup path could still create the real controller client.

0 points
ME
MeiChan1125
Replying to ChenAdams0094

You're right. I blurred two checks. The strict interface catches wrong calls; offline startup also needs to exclude the real client and reject controller endpoint configuration.

8 points
EL
ElenaBarnes0601
Replying to MeiChan1125

@MeiChan1125 So no quiet fallback to the real SDK if a fake method is missing? That would be a horrible surprise.

21 points
ME
MeiChan1125
Replying to ElenaBarnes0601

@ElenaBarnes0601 Yes, treat that as an explicit offline failure. It identifies an unsupported method or unwanted application call and should never trigger controller access.

14 points
SA
SamBell0681
Replying to MeiChan1125

@MeiChan1125 On my setup, the substitute allowed any method name, so a misspelled call passed all offline runs instead of failing where we could easily diagnose it.

17 points
JA
JackBennett0776
Replying to SamBell0681

@SamBell0681 Would you check argument names too, or is matching the return value enough?

9 points
ME
MeiChan1125
Replying to JackBennett0776

@JackBennett0776 Match the documented call signature too. Wrong arguments should fail clearly instead of getting a plausible canned response.

14 points
EL
ElenaBarnes0601
Replying to MeiChan1125

I tried that and found an obsolete helper call in our application. The permissive mock had accepted it without complaint.

10 points
CH
ChenAdams0094
Replying to ElenaBarnes0601

@ElenaBarnes0601 Which SDK version are these fixtures from? Correct shape for the wrong version is still the wrong contract.

6 points
EL
ElenaBarnes0601
Replying to ChenAdams0094

@ChenAdams0094 Our saved examples have the SDK source identifier and matching documentation. I'll keep those attached; loose response files would lose that context.

19 points
JA
JackBennett0776
Replying to ElenaBarnes0601

@ElenaBarnes0601 Can I just invent the missing error cases? We won't have captures for absolutely everything.

6 points
ME
MeiChan1125
Replying to JackBennett0776

Documentation can supply uncaptured contract cases. You can also construct invalid inputs to test resilience, provided they're clearly distinguished from responses actually observed from the controller.

21 points
SA
SamBell0681
Replying to MeiChan1125

@MeiChan1125 I separated my fixtures by origin because someone had mistaken an intentionally malformed test input for an actual controller response. The labels cleared that up.

18 points
EL
ElenaBarnes0601
Replying to SamBell0681

I've settled what this mock is for: checking our documented interface with explicit success and error cases. I'll count it ready only when those checks pass and the offline run attempts no controller connection.

10 points
ME
MeiChan1125
Replying to ElenaBarnes0601

You've given the substitute a clear job while keeping its completion dependent on the response tests and connection checks.

7 points

Add to the discussion

Welcome to Application Robot

Everyone can read the forum. Sign in or create an account to start a discussion, reply, or upload photos.

Forgot your password?

By creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.