Proposal : Sharing Backgrounds Across Cucumber Features.

[Twinkle-Gehlot]

In many test scenarios, we often encounter the need to share similar backgrounds across multiple feature files. These backgrounds, while essential, can grow significantly in size, making feature files less readable and harder to maintain.

While working on my current project, I faced the same challenge of managing large and repetitive backgrounds across multiple feature files.
To address this, I have implemented a solution that allows importing backgrounds from one feature file into another. This approach is inspired by JBehave's initialization stories.

By extracting the common backgrounds into separate feature files and referencing them in the main feature files, I achieved:

• Improved readability: Main feature files are now concise and focused on the test cases.
• Enhanced maintainability: Changes to shared backgrounds are centralized, reducing redundancy.
• Better modularity: Encourages reusability across various test scenarios.

This solution has significantly streamlined our testing process. I’d love to share the implementation details, discuss its potential broader adoption, and explore ways it could be integrated into the Cucumber framework itself.

[mpkorstanje]

You can already do this in Cucucumber!

For example imagine you have a scenario with a complicated background that you want to reuse:

Feature: Belly

  Background:
    Given several complicated steps
    * setup widget "A"
    * setup widget "B"
    * setup widget "C"
    * setup widget "D"

  Scenario: a few cukes
    Given I have 42 cukes in my belly
    When I wait 1 hour
    Then my belly should growl

And the steps to execute it:

public class StepDefinitions {

    @Given("several complicated steps")
    public void severalComplicatedSteps() {
    }


    @When("setup widget {string}")
    public void setupWidget(String cukes) {
    }

    @Given("I have {int} cukes in my belly")
    public void iHaveCukesInMyBelly(int cukes) {
    }

    @When("I wait {int} hour")
    public void iWaitHour(int arg0) {
    }

    @Then("my belly should growl")
    public void myBellyShouldGrowl() {
    }
}

You can consolidate the background into a single step:

Feature: Belly

  Background:
    Given several complicated widgets have been setup

  Scenario: a few cukes
    Given I have 42 cukes in my belly
    When I wait 1 hour
    Then my belly should growl

Which is implemented by invoking the other steps:

    @Given("several complicated widgets have been setup")
    public void severalComplicatedWidgetsHaveBeenSetup() {
        severalComplicatedSteps();
        setupWidget("A");
        setupWidget("B");
        setupWidget("C");
        setupWidget("D");
    }

You can then reuse this background in any other feature file without it being overly long.

Now I suppose there is an unstated reason that motivates you to reuse at the feature level instead of the step definition level?

Note:

• This example directly reuses step definitions, but if your setup is complicated enough you may want to push that into your support code instead and reuse that in the consolidated background step.
• I didn't bother coming up with an expressive name for the consolidated background step, but that would be quite essential to communicate clearly what this step does.

[Twinkle-Gehlot]

Thank you for your input! While consolidating the background into a single step might reduce redundancy, it’s not quite aligned with the problem I’m trying to address.

The goal here is to ensure that background steps remain represented in plain language, such as Given steps, directly in the feature file. This approach ensures the feature file remains accessible and easily understandable for non-technical stakeholders, such as business analysts and end-users, who may not be familiar with Java or the underlying step definitions.

Consolidating steps into a single definition in the Java class makes the feature file less transparent, as the detailed context is hidden in the codebase. Instead, by enabling background steps to be imported directly into feature files in plain language, we can preserve readability and usability while still promoting modularity and reusability.

For example,

Feature: Widget initialization

Background:
Given several complicated steps
* setup widget "A"
* setup widget "B"
* setup widget "C"
* setup widget "D"

Feature : Belly Feature
Initialization : /{path}/{widget-initialization.feature}
Scenario: a few cukes
Given I have 42 cukes in my belly
When I wait 1 hour
Then my belly should growl

Feature : Another Feature
Initialization : /{path}/{widget-initialization.feature}
Scenario: ....
Given: ....
When: ....
Then: ....

[mpkorstanje]

This looks a lot like programming and it makes feature files less self contained. Being plain text and self contained are two primary design goals for Gherkin. So I think it's unlikely that a pull request like that would be accepted.

Have you considered using Gherkin to document what Gherkin step does? For example:

Feature: Common steps for reuse
  Scenario: Document several complicated widgets have been setup
     Given a system in the default state
     When several complicated widgets have been setup
     Then widget "A" has been setup
     And widget "B" has been setup    
     And widget "C" has been setup
     And widget "D" has been setup
     And no other widgets have been setup

This keeps the details of what the step does discoverable in plain language, and also had the advantage of testing that the step does what is says does.

Or, another pattern to consider: For a more complicated system, there can only be so many knobs to twiddle that you might want to summarize them in a table. The exact same table would be repeated in quite a few features, but also allow each feature to be self contained, while presumably still being shorter than the actual steps.

Background: 
     Given the initial setup with the following modifications
        | Enabled widgets | A, B, C, D, E |
        | APR             | 2.3%          |
        | Region          | fr            |
        | Domain          | private       |         

[Twinkle-Gehlot]

Thank you for your response! The solution you suggested works well when the steps are relatively simple or straightforward. However, in scenarios where the steps themselves are complex, combining them into a single step or summarizing them in a table can become cumbersome and potentially reduce clarity.

For example,

     Given table PRODUCT is populated with below data:
     | PRODUCT_ID | COL 1 | COL 2 | COL 3 | COL 4 | .....
     | 123        | Val1  | Val2  | Val3  | Val 4 | .....
    ...... 
    ......

     Given table  ORDER is populated with below data:
     | ORDER_ID | COL 1 | COL 2 | COL 3 | COL 4 | .....
     | 123      | Val1  | Val2  | Val3  | Val 4 | .....
    ...... 
    ......

I’d like to emphasize that my proposed solution would be especially beneficial for teams migrating from JBehave to Cucumber. JBehave offers a similar functionality with its "initialization story" concept, which allows shared setup logic to be reused across stories. Having a comparable feature in Cucumber would make such migrations smoother and provide a familiar paradigm for teams accustomed to JBehave's capabilities.