Adding 'shared background' to feature files?

[mleegwt]

Currently the background steps get executed each time a scenario runs. For some scenarios the background could take significant time and resources. When the background steps create a dataset that is read in multiple scenarios the execution time of the scenarios is mainly influenced by the background.

I would propose to introduce a new keyword shared background (my first suggestion). That would function similar to Java JUnit 5 BeforeAll.

Example:

Feature: Explain this discussion
    Shared background: # Executed once
       Given lengthy and resource intensive preparation is executed
    
    Background:
        Given other test prep
    
    Scenario:
        <scenario 1>

    Scenario:
        <scenario 2>
    # Etc

The regular background is executed each time, the shared background only once.

In some situations parallelism could be an alternative to complete scenarios sooner, however the resource usage remains.

What do you think of this proposal?

Regards,

Michiel

[luke-hill]

This is something that probably wouldn't live inside a single feature. Because I'm assuming you only want this to run once for the entire test execution.

If not you're coupling your tests too rigidly.

If so, then there are mechanisms in-place. Lean on a BeforeAll / AfterConfiguration hook

[mpkorstanje]

Alternatively, if the dataset is only used for some scenarios, but not all. And if the dataset is reusable between scenarios, caching would allow you to reuse the dataset after it has been created. The simplest example would look something like this:

static Dataset dataset;

@Given("a lengthy and resource intensive preparation")
public void setupData(){
    if(dataset == null) {
      dataset = // create data set here.
    }
    return dataset;
}

[vitalets]

I was struggling with the same task and solved it by caching at the step-definition layer rather than at the feature layer.
I started with the simplest approach, similar to @mpkorstanje’s, but realized that things are more complex:

1. In parallel runs, multiple workers can simultaneously access a shared resource. Without a special mechanism (e.g. a mutex with waiting), the resource will be initialized separately for each worker. Here’s an example of how I handle this in JS.
2. How do we properly clean up a resource created in such a shared background? We can’t just use AfterAll, because it might remove the resource too early, while other workers are still using it:

   AfterAll(() => {
     if (dataset) {
       cleanup(dataset); // <- cleanup too early!
     }
   });

   I’m waiting for coordinator hooks mentioned in Global Setup and Teardown in CucumberJS cucumber-js#2614 (comment) and tracked in BeforeAll hook is executed as many workers exist (in case of -parallel option) cucumber-js#1153.

[mleegwt]

Thanks for all the replies! Caching and before all hides the preparation work from the readers of the feature/scenarios.

On the one hand this could sometimes be treated as implementation details. However, Cucumber/Gherkin allows us to describe features/scenarios in such a way that is readable for all concerned.

If the setup is time and resource intensive, is it something we should completely hide from readers of the feature file?

[vitalets]

Caching and before all hides the preparation work from the readers of the feature/scenarios.

For caching, that’s not exactly true: if the step implementation is cached and placed in a regular Background, you’ll get all the benefits: it’s executed once, but visible in all features that use this step.

[mleegwt]

True, however executing only once could be seen as a 'side effect'.