In a Gatling scenario, a checkout step calls a payment provider you are not permitted to load test - how would you decide what to put in its place?

Sooner or later a scenario contains a call you are not allowed to make at load: a payment provider whose sandbox rate-limits you, a partner API with a contractual call budget, a mainframe nobody will let you push. You have three options — call it anyway, delete the step, or substitute something. Gatling gives you a first-class way to substitute, and the interesting part is the judgement around it, not the syntax. ## What `dummy` gives you `dummy(name, responseTime)` builds an action that **emulates** a remote call. It occupies a place in the chain, it is named, it is timed, and it produces a sample — but no packet leaves the machine. Its configuration surface is small and deliberate: - **The name** may be a fixed string, a Gatling expression-language string, or a function of the session. - **The response time** may be a plain integer number of milliseconds, an expression-language string such as `"#{randomInt(200,400)}"`, or a function of the session — so it can vary per virtual user rather than being a constant. - **`withSuccess(...)`** sets the outcome, as a boolean, an expression-language string or a function. If you never call it, the outcome is a success. - **`withSessionUpdate(...)`** takes a session function and applies it as part of the action, so the stand-in can write the attributes the real call would have produced — an order reference, a token, a status — and the steps after it keep working unchanged. Because it is an ordinary action builder, it composes exactly like a request: you can put it inside a group, inside a loop, or store the whole chain in a value. ## Why not just delete the step Deleting the call is the tempting shortcut and it is usually the worst option, for a specific reason: the surrounding **group** timing silently changes meaning. A `Checkout` group that used to contain four calls now contains three, and its number is no longer comparable with any earlier run. A stand-in keeps the shape of the business step intact and makes the substitution visible in the output as a named action, where a reader can see it. ## The judgement, stated as questions 1. **Is that dependency part of what this run is validating?** If the question is "can our checkout hold 500 orders a minute", and the payment provider is on the critical path, then a stand-in answers a different question than the one asked. Say so before the run, not after. 2. **What response time do you attribute, and on what basis?** A measured production percentile for that call is defensible. A round number someone liked is not. Whatever you pick, it is an input to the result, not an output of it. 3. **Should it ever fail?** Real dependencies fail. `withSuccess(false)`, driven by an expression that fails a small share of users, exercises the error path that a permanently green stand-in never will. 4. **What does the stand-in remove from the system under test?** It removes the connection, the TLS handshake, the serialisation, the thread or connection held during the wait — all real costs. A dummy with the right response time does not reproduce the resource the real call would have occupied. 5. **How is it recorded?** The substitution belongs in the run's description, in the simulation's name, or in a comment a reader will actually see. An artefact that hides its own assumptions is worse than no artefact. ## A worked shape ```java ChainBuilder checkout = group("Checkout").on( http("Cart").get("/cart"), dummy("Payment", "#{randomInt(200,400)}") .withSessionUpdate(session -> session.set("paymentRef", "TEST-1")), http("Place order").post("/orders")); ``` The group still spans the whole business step, the stand-in is visibly named `Payment` in the output, and the order request downstream finds the reference it expects. ## When a stand-in is the wrong answer - When the provider is the thing under test. - When the real call holds a scarce resource — a connection from a small pool, a worker thread — whose exhaustion is the failure mode you are hunting. Consider a local stub that really occupies the connection instead. - When nobody will read the caveat. A number without its assumption travels further than the assumption does, and the version that travels is the wrong one. ## The position worth defending Substitution is legitimate engineering, not cheating, **provided** the substitution is named in the output, its parameters are chosen from evidence, and the report says which tier the run did not measure. That is the whole of it, and it is a call a lead should own rather than leaving to whoever writes the scenario.