Background Outline

[jsliacan]

🤔 What's the problem you're trying to solve?

I want to avoid multiplicating Feature files (aggregations of Scenarios) that need to be run under different Background conditions.

Imagine you have n Scenarios about how a user interacts with a running cluster. In a Background, you set up and start the cluster 1x (condition checks if it's already running, if it is, nothing happens) - this saves loads of time by not starting the cluster for each Scenario.

What I need to do is test all these Scenarios on a cluster that runs behind a proxy, offline, online in the open, some other corporate environment, etc. Note: it is not possible to change the defining settings of the cluster after it's started. In short, I need a way to run all Scenarios in the Feature file multiple times over against a different background, and I want this to be explicit to the user who reads the Feature file (not done behind the scenes quietly).

Something like the following Feature file needs to run in different environments:

Feature: User interacts with a running cluster

Background:
   Step read cluster settings
   Step start the cluster with given settings if it's not running yet

Scenario: 
   Step start an app
   Step check that app is running

Scenario:
   Step do some cluster admin work
   Step check that it has effect

Scenario: 
   ...

✨ What's your proposed solution?

Parametrized Background (such that parametrization is controlled from the .feature file) seems like a feature that would find its use. Not sure what the complications might be if this was to be taken seriously...

Feature: User interacts with a running cluster

Background Outline:
   Step read cluster settings
   Step start the cluster in a <env> environment with given settings if it's not running yet
Examples:
   | env |
   | proxy |
   | online unrestricted |
   | offline|

Scenario: 
   Step start an app
   Step check that app is running

Scenario:
   Step do some cluster admin work
   Step check that it has effect

Scenario: 
   ...

⛏ Have you considered any alternatives or workarounds?

The following two options come to mind right away (and I'll probably use the 2nd one in the meantime anyways):

• duplicating the feature files with minor modifications/tags that decide what is run for the setup in the Background
• passing a parameter when executing the tests (a flag of sorts) to inform the setup, then run the feature as it is. This would require an additional testsuite run for each time the feature is executed under different setup.

I saw a similar question on StackOverflow from 3y ago but didn't find an issue about it over here.

Thanks for any tips (if I'm overlooking existing solutions!) and your time in general!

[jenisys]

@jsliacan
What you are suggesting is to extend Gherkin with rather complicated for-loop over Background and Scenario(s) that use this Background steps.

MUCH SIMPLER SOLUTION:

• Gherkin / feature-files are text files
• You can use a textual template generator, like jinja2, to generate multiple *.feature files from a *.feature.in file that uses the template-syntax and contains this for-loop (internally if possible or the build-script provides the for-loop)
• This is just an extra build script step before cucumber run starts
• Because your problem is just a build automation problem

[knee-knee]

I believe this is a limitation of cucumber in general and not just Godog. Looking at the cucumber documentation it seems like this is not possible https://cucumber.io/docs/gherkin/reference/#background. I do agree however this would be a nice feature to have.