How do you use a virtual service to test how a client behaves when its dependency is slow, throttled or failing?

## Why this is the most common reason to stand in a service The paths that break in production are the ones nobody exercises: the dependency was slow, it throttled you, it returned a body the parser had not seen. A real sandbox will not produce those on request. A virtual service will produce them on every run, deterministically, which turns resilience from an intention into a tested property. ## The four families ### 1. Latency Configure a delay on the matched response. The important detail is the *size* of the delay. A tax-filing wizard's submission client is configured with a 250 ms read timeout; the stand-in delays 420 ms. That reaches exactly the same code path as a thirty-second hang, and the 340-case regression pack stays fast. Injecting a long sleep instead is the classic novice move - it proves the same thing and costs the suite minutes. Delay variants worth knowing: a fixed delay, a delay applied to the first chunk only (slow to respond) versus spread across the body (slow to transfer, which some clients time out differently), and a random delay inside a band, which is useful for soak runs but a poor choice inside a deterministic pack. ### 2. Protocol-level faults A clean error status is a *successful* exchange carrying bad news, and it exercises a different branch from a connection that never opened or died mid-flight. Worth injecting: refusing the connection, accepting then closing without a response, closing after headers but before the body ends, and returning garbage bytes where a response was expected. The truncated-body case is the one that catches the wizard-shaped defect, because a parser handed half a document may return a partially populated result rather than raising - which is how a silent data corruption starts. ### 3. Status responses Unauthorized and forbidden (does the client refresh a credential, or retry forever?), not found, conflict, throttled with a retry hint, and the server-error family. Throttling deserves its own case: return the throttling status with a retry hint of two seconds and assert that the client waits rather than hammering, and that its retry budget is finite. A client that treats throttling as a generic failure and retries immediately turns a provider's brownout into an outage. ### 4. Malformed payloads Three distinct rungs, and candidates usually name only the first: - **Syntactically invalid.** Truncated or corrupt bytes. The deserializer should raise. - **Syntactically valid, semantically wrong.** A number where a string was expected, an unknown enumeration value, a null in a required position. This is where lenient parsers quietly produce a default value. - **Valid and plausible, but wrong for the request.** A receipt for a different submission identifier. Only an assertion that correlates request to response will catch it. ## Stateful scenarios Single-response rules cannot express recovery. A stand-in that supports scenarios lets a rule advance a state on each matched call: state *start* returns a server error and moves to *attempt-2*, which returns a throttling status and moves to *attempt-3*, which returns the receipt. Now the case proves the whole retry sequence - that it recovers, that it stops in time, and that it does not file the return twice on the way. The same mechanism expresses a dependency that is healthy, then degrades, then recovers, which is how you test a circuit-breaking client without waiting on real weather. ## What you assert The mistake is to assert on the stand-in. The stand-in is the stimulus; the client is the subject. Assert: - **Call count and spacing** from the request journal - three attempts, not eleven, with increasing gaps. - **Idempotency.** The retry carried the same idempotency value, so the gateway can deduplicate. - **Error mapping.** A throttle surfaced as *try again shortly*, not as a stack trace or a validation message. - **State after failure.** This is the one that matters most in the tax-filing example: after the timeout, is the return marked submitted locally? A wizard that records a submission it never confirmed is the silent data corruption, and only an assertion on persisted state after an injected fault will find it. ## Practical cautions Keep injected-fault cases in their own group; mixing them with happy-path rules on one shared stand-in leads to a fault leaking into unrelated cases. Make the injected behaviour explicit in the case name, so a failure reads as *timeout path* rather than as a mystery. And remember the limit of the technique: you are testing your client's response to a *believed* failure mode. That the real dependency actually fails that way is a separate claim, and it decays like any other.