Using Cucumber Background Steps Effectively

Cucumber Background steps shared preconditions across scenarios in feature files. Learn when to use them, how parameter interpolation works, and when to switch to hooks for cleaner BDD maintenance.

The Problem: Setup Noise in BDD Feature Files

When writing BDD feature files, repeating the same Given steps across every scenario creates noise. It obscures the unique behavior being verified and makes the feature file harder to maintain when the setup process changes.

Background Across Cucumber Runtimes

Cucumber Background keyword executes once before every scenario in the feature file that declares it. The semantics are consistent across Ruby, Java, and JavaScript runners, but version boundaries and scope nuances matter.

Cucumber JVM (Java & JUnit)

Background steps appear under the feature header and have been stable since Cucumber 3.0. This version supports data tables and dependency injection without breaking changes, making it safe to use in modern Java projects.

Cucumber.js

JavaScript runners implement Background with identical Gherkin semantics. However, sharing setup across multiple feature files requires explicit before hooks, because Background scope is confined to a single feature file.

Parameter Interpolation in Background Steps

Background steps follow the same step definition binding rules as regular scenarios. Placeholders such as code '' are resolved by step definitions that accept string arguments, enabling dynamic preconditions without code duplication.

Feature: Online checkout

Background:
    Given a user '' with a valid session
    And the cart is empty

Scenario: Add item to cart
    When I add 'Organic Coffee' to the cart
    Then the cart count should be 1

Scenario: Apply discount
    Given the cart contains 'Organic Coffee'
    When I apply code 'SAVE10'
    Then the total should reduce by 10%

When to Choose Background Over Hooks

Use Background when the preconditions are business-readable, belong to a single feature file, and number fewer than eight steps.
Use Hooks when setup spans multiple feature files, involves technical state (browser launch, OS-level configuration), or requires per-scenario teardown.

Background sections longer than eight to ten steps risk creating hidden dependencies. A scenario read from top to bottom may lose track of the initial state, and future maintainers might struggle to discern what is essential versus inherited.

Trade-offs and Limitations

File-scoped only: Background applies strictly to the feature file it resides in. Cross-file coverage demands a global Before hook or a shared step definition called from each Background.
State isolation: Because Background runs before every scenario, any database or service-level mutation can affect test independence. Pair Background with transactional fixtures or scenario-level cleanup to preserve isolation.

Verification Checklist

Run cucumber --version; confirm the major version is 3.0+ for JVM or 2.x+ for Ruby/JS to ensure Background syntax stability.
Execute a feature file with a Background step and confirm the step runs once before each scenario's steps in verbose output.
Check that no scenario fails because it requires state accidentally moved into a Background it doesn't need.

Cucumber Background Steps: Scope, Syntax, and When to Use Hooks Instead