Giving each parallel test worker its own current-case context fixes cross-talk; what does a helper that reads that context implicitly still cost you?

Per-worker scoping and explicit parameters solve two different problems, and it is easy to declare victory after solving only the first one. ## The two problems, separated Scoping the current-case context to each test worker solves a **correctness** problem: two cases can no longer overwrite each other's value, because there is no longer one value to overwrite. It solves nothing about **visibility**. A helper that reaches out for the acting user rather than receiving it still has an input that does not appear in its signature — and scoping arguably makes that input harder to find, because the value now lives somewhere less obvious than a single named slot. Name the thing precisely. An **ambient** value is one a unit of code reads from its surroundings instead of receiving from its caller. The surroundings might be a slot bound to the thread running the case, a per-case context object the runner hands to lifecycle hooks and stashes somewhere reachable, or a scope the runner opens and closes around each case. The mechanism differs; the property is identical — the caller does not supply it and cannot see that it is needed. ## The three costs 1. **Local reasoning stops working.** Reading the helper is no longer enough to know what it does. Its behaviour depends on which setup hook ran, in what order, and whether that hook set the value for this case or left the previous one in place. The answer lives in a different file, and often in a base type several levels up. 2. **Reuse outside a case fails or, worse, lies.** A seeding script, a one-off repair job, or a helper called from a fixture-building step has no case in scope. The read then returns empty and the helper throws somewhere unrelated, or it returns a default and quietly does the wrong thing. 3. **Nesting has nothing to inherit.** A case that fans out its own concurrent work — issuing several requests at once to reproduce a race, or driving two participants in one flow — runs that work somewhere the scope does not reach. The fanned-out code reads empty, or reads whatever the parent scope contained, and neither is what the author intended. ## The comparison in one view | Property | Ambient per-case value | Passed as a parameter | | --- | --- | --- | | Inputs visible in the helper's signature | no | yes | | Callable with no case in scope | no | yes | | Survives work fanned out inside one case | no | yes | | Two cases can use different values at once | yes, once scoped | yes | | Cost of adding one more value | one line | every signature on the path | The last row is the honest reason ambient context wins arguments. Adding a value costs one line today and is paid for later by everyone who reads the helper. ## When ambient is genuinely the right answer Ambient is defensible for facts that belong to the **run** rather than to the **call**, where no caller would ever choose a different value: - a correlation tag attached to every outbound request so the run can find its own traffic - the directory the run writes failure artefacts into - the logical name of the deployed target, when every case in the run uses the same one The test is a question: *would any caller ever want to pass something different here?* If yes, it is an input and belongs in the signature. If the answer is genuinely never, ambient costs little. ## Reducing the cost without abandoning either A workable middle position keeps the scoped context as the storage mechanism, and forbids helpers below a certain layer from reading it. Business-action helpers receive what they need; only the thin layer directly beneath the case body is allowed to consult the ambient value and pass it down. That gives short case bodies and reviewable helpers at the same time, and it makes the ambient set finite rather than growing by one every time a helper needs something new. Two other habits pay for themselves. First, make an unset ambient read **raise** rather than return empty — the empty default is what turns a design smell into a silent wrong answer. Second, when a helper needs three or four ambient values, treat that as the signal to name the group and pass it as one object; four invisible inputs is not three more of the same problem, it is a concept that has never been given a name.