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

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

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

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.

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

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

@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.

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

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

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

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

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

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

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.

@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.

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.

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