The format of the feature files used in Cucumber or SpecFlow is very simple. The format (or grammar), called Gherkin, was intentionally designed to be simple, so that the specification written in these files are kept simple and understandable. There are no loops or ifs. The only special structure you can make in a feature file is the “Background” section. In the background section you can list one or more given steps that will be implicitly included in every scenario of the file. So you can use it to extract common preconditions from the scenarios to avoid duplication. Sounds simple, but still, half of the BDD practitioners like and use this feature, while the other half doesn’t. Where do you belong to? Here is a list of pros and cons.

Let’s start with an example. We are in a book shop (again) and describe how the shopping cart should work…

With using the background section, this can be simplified to

The steps you define in the background section will be included in every scenario of the file. This means that the background steps will be executed for every executed scenario, not only once. In our example they would be executed twice. It works like the test setup in the testing frameworks (and not like the test fixture setup). You cannot have more than one background section in the feature file and it has to be defined before the first scenario.

So let’s see why we should or should not like it!

We like the background, because…

With the background you can simplify the feature file and avoid duplication. The steps that are common in all scenarios of the file are usually less important than the other steps, so extracting them into a separate section might make the scenarios even more focused and cleaner (like the “remove” scenario in our example). Still, if you need more details, you can check the background section too. I think this is pretty obvious.

We don’t like the background, because…

The counter arguments are a bit more tricky. I have collected the ones I’ve heard about into a list.

• The background section might be confusing, because a lot of people think that the background steps will be executed only once in the beginning and not for all scenarios.
• For longer files, it is easy to lose context, especially if the background section has been scrolled out. You get the false illusion that you see the whole story when you look at a scenario, but you don’t.
• Moving scenarios across feature files is much harder when you use backgrounds because you have to synchronize the background steps of the source and the target feature file.
• If the preconditions of the different scenarios are similar but not exactly the same, people tend to harmonize their preconditions in order to use the background. E.g. if the addition needed two books in the system, but the removal needs only one, than you can say that both scenarios can run with two books. This might be still useful if done carefully, but after a while the background steps can overgrow and no one will be able to tell why (ie for which scenario) was a certain step included there.
• After a couple of nice scenarios with the same preconditions you will find another that does not match. A Murphy’s law kind of thing. So you either ban the new scenario to exile into another feature file or remove the background section and include its steps to the previous scenarios. Pretty frustrating.

So then what?

As you might see, the “con” part was longer than the “pro”, so you might think that the conclusion is that one should not use backgrounds. Many people think so too. In my opinion however, if you use it in a disciplined way and you take care that your feature files don’t get very long, backgrounds can be useful and can be used safely. But if you have bad feelings regarding a particular feature file, rather don’t use it.

Regardless of whether you like it or not, make sure that you decide on the “background strategy” as a team and stay loyal to the decision.