In Gatling, how do you wrap several actions of a scenario in a named group, and how does the Java spelling differ from Scala's?

A scenario made only of requests reports only requests. A group puts a name around a stretch of the chain so that the run also has a record of the **business step** — "Checkout", "Login", "Search and open a product" — rather than just the four calls that happen to implement it. ## The two spellings | SDK | form | |---|---| | Java | `group("Checkout").on(req1, req2)` | | Kotlin | `group("Checkout").on(req1, req2)` | | JavaScript / TypeScript | `group("Checkout").on(req1, req2)` | | Scala | `group("Checkout")(req1, req2)` | The divergence is not cosmetic — it is the same divergence you see in every wrapping construct across these SDKs. Scala can take a second parameter list, so the wrapped block is simply the second argument group. The Java API has no such syntax, so `group(name)` returns an intermediate object that exists only to expose `on(...)`. Kotlin and the npm SDK sit on the Java shape and inherit `.on`. A candidate who writes Scala's form in a Java simulation will not get a subtle bug — it will not compile — but the reverse habit is a common source of confusion when a team reads examples written for the other SDK. ## What a group actually is A group is **not** a container object that holds a sub-scenario. Internally, `group(name).on(chain)` produces a small chain of its own: a group-start action, then the wrapped chain's actions, then a group-end action. That triple is then spliced into the enclosing chain like any other steps. Two useful consequences follow: 1. **A group composes exactly like anything else.** `group("Checkout").on(...)` evaluates to a builder you can assign to a chain value, pass around, and `exec` from several scenarios. There is no special "group type" to learn. 2. **Groups nest naturally.** Because the markers just bracket a region of the chain, putting one group inside another produces a nested region. A virtual user's current position is tracked as a list of enclosing groups, which is how nesting is represented in the run's output as a tree. ## Naming the group In the Java API, `group` accepts either a `String` — which may be a Gatling expression-language string, so the name can interpolate a session attribute — or a `Function<Session, String>` for a name computed at run time. That is genuinely useful ("Checkout – #{paymentMethod}") and genuinely dangerous: a name that varies per user explodes the number of distinct groups in the output, which is a cardinality problem, not a Gatling problem. Keep computed names to a small, closed set of values. ## What the group buys you Beyond naming, a group records its own timing entries alongside the requests inside it, including a cumulated response time for the block. That gives you a per-business-step number to look at rather than forcing you to reconstruct one from the individual requests. What the HTML report charts for a group, and how a post-run assertion addresses a group by path, are separate surfaces with their own rules — the composition question is only how the block gets built. ## A worked shape ```java ChainBuilder browse = group("Browse").on( http("Home").get("/"), http("Category").get("/books")); ChainBuilder checkout = group("Checkout").on( http("Cart").get("/cart"), http("Place order").post("/orders")); ScenarioBuilder shopper = scenario("Shopper").exec(browse, checkout); ``` Each group is an ordinary chain value; the scenario composes them the same way it would compose ungrouped chains. ## What happens when something inside a group fails A group records more than a name. When the block ends, Gatling emits an entry carrying the group hierarchy, its start and end timestamps, a cumulated response time, a start-to-end duration and a **status**. So the outcome of what happened inside the block is carried by the group itself, not only by the individual requests — a checkout that failed at its third call is visible as a failed checkout, without a reader having to correlate four request lines by hand. Grouping changes nothing about control flow, though. A failure inside a group does not skip the rest of the group, and a group is neither a retry boundary nor a rollback boundary; those are separate error-handling constructs in the DSL. ## Practical guidance - Group by **business step**, not by technical convenience. "Checkout" is a step a product owner recognises; "Third batch of calls" is not. - Keep group names stable across runs. A renamed group is a new group, and comparing two runs across a rename is comparing nothing. - Do not nest more deeply than the report is going to be read. Two or three levels is usually the useful limit. - Remember that grouping does not change what is sent. It changes what is recorded, and nothing else about the traffic.