What does a Background section in a feature file do to the scenarios below it?

### What a Background block is A **Background** is a block of context steps placed once, near the top of a feature file, above the scenarios. Its steps are written in exactly the same language as a scenario's own context steps, and they describe state that is true before every scenario in that file begins. The intent is deduplication of *narrative*, not of *code*: if eleven scenarios all open with the same two lines of context, those two lines stop carrying information and start being noise, and the Background lifts them out so each scenario's own text is only what makes that scenario different. ### The execution semantics people get wrong The single most common misunderstanding is that a Background runs **once per file**. It does not. It runs **again before every scenario in the file**, from a clean starting point, so that scenarios stay independent and order-free. If a Scenario Outline sits in the file, the Background runs again for every row of its Examples table too, because each row is expanded into its own scenario. That has two consequences worth stating out loud in an interview: * **Isolation is preserved.** No scenario inherits the residue of the one before it; each gets the same freshly established context. * **The cost is multiplied.** A Background step that takes four seconds costs four seconds per scenario, not four seconds per file. In a 340-case regression pack, a single careless setup step in a widely used Background is the difference between a pack that finishes over coffee and one that does not finish at all. A Background is also restricted in what it should contain: **context only**. Putting the action under test there means every scenario in the file exercises an event that none of them names, and the scenarios stop being readable specifications. Putting an assertion there means a failure is reported against a scenario that never claimed to check that thing. Most parsers will happily accept those keywords in a Background; the constraint is a design rule, not a syntax rule, which is exactly why it is worth asking about. ### The coupling it hides Consider a feature file for a **hotel booking channel manager** — the component that pushes room rates and availability out to distribution channels and pulls reservations back. Someone writes: ``` Feature: Rate and availability distribution Background: Given the property has 62 bookable rooms And the property is connected to 4 distribution channels And each channel has acknowledged the current rate plan ``` Every scenario below now begins in a world with four connected channels and an acknowledged rate plan. A scenario about *rejecting a negative nightly rate* does not care about any of that, but it pays for it and, worse, depends on it. Three things follow. **Action at a distance.** A reader who lands on the eighteenth scenario cannot judge whether its outcome is correct without scrolling back to the top of the file. The scenario is no longer a self-contained example; it is a fragment that only means something in context. That is the readability payoff of the whole format being spent, not earned. **A shared blast radius.** The acknowledgement step calls out to four channel connectors. When one of them develops **an intermittent timeout**, the failure does not land on the scenarios about channel acknowledgement — it lands on *every scenario in the file*, including the pure rate-validation ones. A triage engineer reading the report sees eighteen unrelated red scenarios and no signal about the real fault. **Edit pressure.** When a new scenario needs a fifth channel, the tempting fix is a fourth Background step. It is one line, and it silently changes the starting state of every existing scenario in the file. Backgrounds decay in exactly this direction: each addition is locally cheap and globally expensive. ### How to keep one healthy * Keep it to a couple of steps that are genuinely true for **every** scenario in the file, and that a reader would take for granted rather than need to know. * If a step is needed by some scenarios but not others, it belongs **in those scenarios**, however much duplication that creates. Duplication in specification text is much cheaper than a hidden precondition. * If the Background is long because the file covers several capabilities, the file is the problem — split it, or group the scenarios under separate rule blocks where the dialect supports rule-scoped context. * Slow, purely technical setup that no business reader needs (seeding a datastore, starting a stub of an external service) is better handled in the automation layer's setup hooks than written as prose nobody reads. * Do not attempt to *store* state in the Background for later scenarios. It re-runs, and anything it created is expected to be re-created; a suite that depends on leftovers from a previous scenario is order-dependent by construction. A useful review heuristic: read a scenario in the middle of the file on its own. If you cannot tell whether the Then line is right, the Background is carrying information the scenario needed to state itself.