A feature file's scenarios keep failing on shared setup they don't use — how do you restructure it?

### Reading the symptom "Scenarios fail on setup they do not use" is a structural diagnosis, not a flaky-test diagnosis. It says the feature file has accumulated shared context — typically a Background block, sometimes an ever-growing chain of Given steps copied into every scenario — that most of the scenarios below it neither need nor mention. The failures are real; they are just landing on the wrong scenarios. The mechanism is worth being precise about, because the fix follows from it. Shared context in a feature file re-runs before **every** scenario in that file, including every expanded row of a Scenario Outline. So the reliability of the whole file is the reliability of its least reliable shared step, multiplied by the number of scenarios. In a **hotel booking channel manager** whose file opens with "Given each distribution channel has acknowledged the current rate plan", a connector that develops **an intermittent timeout** does not fail one scenario about acknowledgement; it fails the rate-validation, currency-rounding and overbooking scenarios too. In a **340-case regression pack**, one such file turned a single flaky dependency into twenty-three red scenarios a morning, none of which named the actual fault. ### The restructuring moves, roughly in order **1. Shrink the shared context to what is universally true.** For each step, ask: would every scenario in this file be *wrong* without it? If the honest answer is "only about half of them", move it down into those scenarios. Duplicating a Given line across four scenarios is cheaper than a precondition that binds fourteen. This alone usually fixes the blast-radius problem. **2. Split by rule.** A feature file that needs five lines of shared context is usually covering more than one capability. Group the scenarios that illustrate a single business rule together — many dialects offer a rule-level block for exactly this, and where it exists each rule may carry its own scoped context, so the acknowledgement steps sit only above the acknowledgement scenarios. Where the dialect has no such block, split the file. The heuristic for both: if the feature's own title needs the word "and", it is two features. **3. Move technical setup out of the prose entirely.** Seeding a datastore, standing up a stub of an external dependency, resetting a clock — none of that is behaviour a business reader wants to read, and none of it belongs in the specification text. It belongs in the automation layer's setup, invisible to the file. What stays in the file is only the domain-level state a reader needs to judge the outcome. **4. Make the dependency honest where it must stay.** If some scenarios genuinely require a live channel connection, group and tag those so the fact is visible in the file and can be selected against, rather than leaving it implicit in a shared block at the top. **5. Push cases down a level.** A file that has grown heavy is often carrying enumeration rather than illustration — a large Examples table of near-identical rows. Keep the rows that illustrate the rule's boundaries; move the rest to a cheaper check that does not pay the scenario-level setup cost at all. ### What an interviewer is listening for The weak answer is a stabilisation answer: add a retry, extend a timeout, quarantine the reds. Those may be worth doing for the underlying dependency, but they do not touch the reason unrelated scenarios failed. The strong answer names the coupling, and states the invariant it is restoring: **a scenario should fail only for a reason it names.** Everything above is in service of that. The second thing being listened for is a cost argument that is not purely aesthetic. Shared context re-runs per scenario, so it is simultaneously the largest reliability multiplier and often the largest time multiplier in the pack; shrinking it makes the pack faster and the reports readable at the same time. Being able to quantify that — "four seconds of shared setup across a 340-case pack is roughly twenty-two minutes of wall clock spent re-establishing state" — is what separates an opinion from a plan. ### The sequencing, and what it costs Restructure incrementally: take the worst file, move its shared steps down, split it by rule, and measure the red count and the run time before and after. Doing it wholesale across a large pack in one change makes the diff unreviewable and, if something regresses, unbisectable. Expect the specification text to get *longer* — that is the trade being made. Repetition that a reader can see is worth more than economy that a reader has to reconstruct by scrolling, and a file whose scenarios each stand alone is one that a domain expert can review a scenario at a time. If the team resists on the grounds of duplication, the counter is that a feature file is a document for humans, and the automation layer beneath it is where duplication should actually be removed.