How do you pass state between the step definitions of one scenario without using globals?

A scenario is one narrative, but its steps are separate functions with no call relationship. The context step that creates a teacher, the event step that acts, and the outcome step that asserts all need to see the same identifiers. How that channel is built determines whether the suite can be run in any order, in parallel, and repeatedly against a live environment. ## The scenario-scoped context object The standard answer is a small holder object whose lifetime is exactly one scenario. The runner constructs it before the first step and discards it after the last, and it is supplied to each step definition that declares a dependency on it — usually by **constructor injection** into the class or module holding the definitions, so no definition reaches out for it. Because a new instance exists per scenario, nothing leaks between scenarios by construction, and a scenario cannot accidentally rely on a predecessor. Some runners call this the scenario's *world*; the mechanism matters more than the name. ## What belongs in it Keep it thin and typed. - **Keep in:** the identifier of the record the context steps created, the handle or response the event step produced, and the values a later step must assert against. - **Keep out of it:** assertions, driver internals, anything a helper could recompute, and anything that exists only because two definitions were too fat to be split. A context object that has grown thirty fields is usually telling you the definitions have become procedures sharing a scratchpad. Prefer a few purpose-named holders — one for the identities the scenario created, one for the last response — over a single untyped bag of keys, which turns a compile-time question into a run-time one. ## Why process-wide state fails Module-level or process-wide variables outlive the scenario, and three things follow: - **Order dependence:** scenario B passes only when scenario A ran first, so the suite is green as a whole and red when a single scenario is run alone — the fastest way to make people stop trusting it. - **Parallelism:** once scenarios run concurrently, shared mutable state is read and written by unrelated narratives at once, producing failures that look like flakiness. - **And correctness of the assertions themselves:** leftover state can make a scenario pass for reasons it never established. In the school-timetable-planner suite, a context step elevated a teacher to the timetable-editor role and stored the elevated session in a process-wide variable; a later scenario meant to assert that an ordinary teacher *cannot* edit a colleague's timetable reused that session, performed the edit successfully, and reported green. A permission escalation was live in the product and the suite was asserting that it was not. ## Parallelism raises the stakes Scenario suites tend to be the slow tier, and the usual way to hold a time budget — say a 92nd-percentile scenario time of 7.4 seconds — is to run scenarios concurrently. Concurrency is exactly what shared state forbids, so the state design decides whether that lever exists at all. It also pushes isolation past the glue into the data: two concurrent scenarios that both create "the teacher" collide in the database as surely as in a variable. Generating a **unique key per scenario** — a name or identifier salted with a per-scenario token — removes both collisions at once. ## Teardown that leaves nothing behind Two rules carry most of the weight. 1. First, **cleanup goes in an after hook, not in a final Then step**: after a step fails, the remaining steps of that scenario are skipped, so a trailing cleanup step is exactly the code that does not run on the runs where cleanup matters most. Hooks run regardless of outcome. 2. Second, **prefer *not needing* cleanup**: data created fresh and uniquely per scenario, and read-only reference data set up once for the whole run, beat elaborate delete logic. Where cleanup is unavoidable: - make it idempotent and independent of how far the scenario got; - tear down in the reverse order of setup; - and register hooks against tags so that only scenarios that touched an external system pay for its cleanup. State outside your process — files, queues, third-party sandboxes, a mail catcher — never disappears on its own and needs explicit handling; state inside a transaction that the exercised code shares can sometimes be rolled back wholesale, which is the cheapest teardown there is when the architecture allows it. ## The interview signal A strong answer connects the three things: a per-scenario context object gives **isolation**, isolation makes **any-order and parallel execution** possible, and **hook-based teardown plus unique data** keeps the environment clean enough that the isolation survives repeated runs. A weak answer names a global variable and stops, or proposes to fix order dependence by fixing the order.