2
votes

I have a little over a month working with SpecFlow and got to a point where I configured a Background Scenario to setup/verify common data on a database, so the next step was trying to reuse the background for several feature files, to avoid cutting and pasting.

It has been asked before but I expected something else, more user-friendly, just as the Background scenario is easy to understand and update:

Background:
Given I have created the following currencies:
| Code | Name                 |
| USD  | United States Dollar |
| EUR  | Euro                 |

And I have created the following countries:
| Code | Currency | Name          |
| US   | USD      | United States |
| ES   | EUR      | Spain         |
| IT   | EUR      | Italy         |

I found a quite naive solution that is working (or at least seems to, so far), but I'm concerned it may lead me the wrong way, because of my shallow knowledge of SpecFlow.

Taking a look at the generated code for a feature file I got to this:

  1. Create a "feature" file that only has the background scenario, named something like "CommonDataSetup"

  2. Create a step definition like:

    [Given(@"common data configuration has been verified")]
    public void GiveCommonDataConfigurationHasBeenVerified()
    {
        // this class is inside the generated feature file
        var commonSetup = new CommonDataSetupFeature();
        var scenarioInfo = new ScenarioInfo("Common data configuration", ((string[])(null)));
    
        commonSetup.FeatureSetup();
        commonSetup.ScenarioSetup(scenarioInfo);
    
        commonSetup.FeatureBackground();
    
        commonSetup.ScenarioCleanup();
        commonSetup.FeatureTearDown();
    }
    
  3. In the Background of the other feature files write:

    Background:
    Given common data configuration has been verified 
    

So now I can reuse the "common data configuration" step definition in as many feature files I need keeping DRY, and background scenarios can be much shorter.

I seems to work fine, But I wonder, is this a the right way to achieve background reuse?

Thanks in advance.

2

2 Answers

2
votes

If you have a conversation with a business person who wants the feature, they probably don't say "Given common data configuration has been verified..."

They probably say something like, "Okay, you've got your standard currencies and country codes..."

Within that domain, as long the idea of standard countries and currencies is really well-known and understood, you don't need to include it. It has to be the case that every single person on the team is familiar with these, though. The whole business needs to be familiar with them. If they're that completely, totally familiar, then re-introducing a table full of them at the beginning of every scenario would be waste.

Anything you can do to eliminate that waste and get to the interesting bits of the scenario is good. Remember that the purpose of the conversations is to surface uncertainty and misunderstandings, and nobody's likely to get these wrong. The automation is a record of those conversations, and you really don't even need to have much of a conversation for this step.

Do have the conversations, though. Even if it's just one line and everyone knows what it is, using the business language for it is important. Without that, you'll end up discussing these really boring bits to try and work out what you each mean by "common data configuration" and "verify" before you can move on to the interesting parts of the scenarios.

Short version: I'd expect to see something like:

Given standard currencies and country codes
When...

You don't even need to use background for that, and however you implement it is fine. If you have a similar situation with standard data that's slightly less familiar, then include it in each feature file; it's important not to hide magic. Remember that readability trumps DRY in tests (which are really records of conversations).

1
votes

I understand where the need comes, but reusing the same background in different feature files is against the idea behind Gherkin.

See https://github.com/cucumber/cucumber/wiki/Gherkin

Gherkin is the language that Cucumber understands. It is a Business Readable, Domain Specific Language that lets you describe software’s behaviour without detailing how that behaviour is implemented.

With the "Given common data configuration has been verified" step it is not more business readable.

Additional your current implementation messes with the internal state of SpecFlow. It is now somehow working, but when you will get in trouble with it.

If you need something setup in every test, did you had a look at the various Hooks? http://www.specflow.org/documentation/Hooks/

With an [BeforeScenario]- hook you could setup your tests.