Background: for Shared Setup

Learning Objectives

By the end of this lesson you will be able to:

• Write a Background: block with correct syntax and placement
• Explain exactly when its steps run relative to each scenario
• Recognize when a repeated precondition is a candidate for extraction

The Problem: The Same Precondition, Copy-Pasted Everywhere

Imagine a feature file testing an admin panel. Every single scenario needs an admin user logged in before anything else happens:

Feature: Admin user management

  Scenario: Admin deactivates a user account
    Given an admin user is logged in
    And the user list contains "jsmith"
    When the admin deactivates "jsmith"
    Then "jsmith" no longer appears in the active user list

  Scenario: Admin resets a user's password
    Given an admin user is logged in
    And the user list contains "jsmith"
    When the admin resets the password for "jsmith"
    Then "jsmith" receives a password reset email

  Scenario: Admin promotes a user to moderator
    Given an admin user is logged in
    And the user list contains "jsmith"
    When the admin promotes "jsmith" to moderator
    Then "jsmith" has moderator permissions

Two lines — "an admin user is logged in" and "the user list contains 'jsmith'" — are copy-pasted into every scenario. That's not just repetitive to read; if the login precondition ever changes (say, admins now need MFA), you have to find and fix it in every scenario.

The Fix: Background:

Background: lets you write those shared steps exactly once, at the top of the Feature file, before the first Scenario:. Its steps run before every scenario in that feature, as if they'd been prepended to each one automatically:

Feature: Admin user management

  Background:
    Given an admin user is logged in
    And the user list contains "jsmith"

  Scenario: Admin deactivates a user account
    When the admin deactivates "jsmith"
    Then "jsmith" no longer appears in the active user list

  Scenario: Admin resets a user's password
    When the admin resets the password for "jsmith"
    Then "jsmith" receives a password reset email

  Scenario: Admin promotes a user to moderator
    When the admin promotes "jsmith" to moderator
    Then "jsmith" has moderator permissions

Nothing about the behavior being tested changed. Each scenario still logically starts from "an admin is logged in and jsmith exists" — that fact is just stated once instead of three times.

Placement and Semantics, Precisely

• Background: must appear at the top of the Feature, after the Feature: line and before the first Scenario:.
• A Feature file can have at most one Background: block.
• Its steps execute fresh before each scenario runs — not once for the whole file. If a scenario modifies state, the next scenario still starts from the same clean Background state, not from wherever the previous scenario left off.
• Steps inside Background: use the same Given/When/Then/And/But keywords as any scenario — most commonly Given, since a Background is almost always describing preconditions.

When to Reach for It

The signal is simple: if you notice yourself typing the identical Given step (or steps) at the top of three or more scenarios in the same file, that's your cue to extract a Background:. One repeated line might be a coincidence; three is a pattern.

Pro Tip: A Background is scoped to a single Feature file only. If you find yourself wanting the "same" Background across multiple feature files, that's usually a sign those scenarios belong together in one file — or that the shared setup should live in step-definition helper code, not in Gherkin.

Key Takeaways

• Background: sits at the top of a Feature, before any Scenario:, and a Feature has at most one
• Its steps run before every single scenario in that feature — written once, applied to all
• Extraction is worth doing once a precondition repeats across three or more scenarios
• Background is scoped to one Feature file; it doesn't span across files