What does Gherkin's Rule keyword group, and how does a Background under a Rule differ from one at Feature level?

## What `Rule` groups `Rule` is a Gherkin keyword that sits **between `Feature` and the scenarios**. It names one business rule and gathers the concrete examples that illustrate it, so a feature file can hold several rules without splitting into several files or falling back on naming conventions in scenario titles. The nesting is strict: ``` Feature: <- one per file Background: <- optional, applies to everything below Rule: <- zero or more Background: <- optional, applies only inside this Rule Example: <- or Scenario:, same keyword Scenario Outline: Scenario: <- scenarios may also sit directly under Feature ``` Under a `Rule` you write `Example:` or `Scenario:` — they are synonyms, and `Example` is the reading that pairs naturally with a rule ("this rule, these examples"). A `Rule` may carry its own free-form description lines, its own tags, and its own `Background`. It may not nest inside another `Rule`. ## Two `Background` scopes, not one This is the part interviewers actually probe, because a file can now have two `Background` blocks and candidates guess at how they compose. | | `Background` under `Feature` | `Background` under `Rule` | |---|---|---| | Applies to | every scenario in the file, **including** those inside every `Rule` | only the scenarios inside that one `Rule` | | How many | at most one per file | at most one per `Rule` | | Position | before the first scenario **and** before the first `Rule` | before the first scenario in that `Rule` | | Order for a scenario inside a `Rule` | runs **first** | runs **after** the feature-level one | | Shared with sibling rules | yes | no — each `Rule` needs its own copy | So for a scenario inside a `Rule` that has its own `Background`, the executed sequence is: feature-level `Background` steps, then rule-level `Background` steps, then the scenario's own steps. For a scenario written directly under `Feature`, only the feature-level `Background` runs. There is no inheritance in the other direction: a rule-level `Background` never leaks out to sibling rules, and it never *replaces* the feature-level one. ## What `Rule` does not change `Rule` is a grouping and a scoping construct for `Background` — nothing more. It does **not**: - run its scenarios in isolation, in a separate process, or in a shared state scope; - make its scenarios share one instance of anything; - reorder or repeat scenarios; - change how steps bind to step definitions. Two things it *does* affect are worth knowing. Tags placed on a `Rule` line are inherited by the scenarios beneath it, so a tag expression that selects a tag written on the `Rule` selects all of them. And reporting output carries the rule as structure, so generated documentation can group the examples under the rule's name rather than presenting a flat list of scenarios. ## Using it on a suite two teams edit Take a school-meal ordering service whose feature file covers ordering. Two genuinely different rules live there: *orders close at the daily cut-off*, and *free-meal pupils are never charged*. Written flat, the file has one `Background` that has to satisfy both, and it drifts: the cut-off clock is set up for scenarios that do not care about the clock, and the eligibility roster is loaded for scenarios that never look at it. Every scenario then pays for setup it does not use, and each team's additions push the shared `Background` further toward being a union of everything. With `Rule`, the file-level `Background` shrinks to what is genuinely universal — the kitchen roster is loaded — and each rule carries the setup only its own examples need. The two teams stop editing the same block. When a scenario is added under the wrong rule the mismatch is visible in review, because the rule states the behaviour the example is supposed to illustrate. Two cautions. First, resist making `Rule` a folder: if a rule accumulates twenty examples, that is a sign the rule is really several rules, or that the examples are variations that belong in an outline. Second, a rule-level `Background` is not shared, so setup needed by two rules is either duplicated in both or promoted to the feature level — and promoting it means every scenario in the file pays for it. That tension is the actual design decision `Rule` puts in front of you.