2

My colleague and I are having a debate about when its appropriate to use the 'background' keyword.

the test scenario is to confirm that the correct country codes appear when you enter a telephone number.

Now the way the test script was written in a way that was so vague it wasn't immediately apparent what it was supposed to do. I spoke to the author of the test and got more clarification.

As our product is so large (100 + countries). I managed to reduct it down to 10 countries. This will require me to create 10 accounts and ensure they are verified.

My question is this. As the this test is so initially super vague it would make sense to create a 'background gherkin' step that will clarify that it will only be for 10 regions and to list those regions so that anyone else who picks up the test will know exactly what this test is supposed to do. I admit that it's one scenario but it is a critical scenario so it's essential that stake holders know what we are trying to achieve and what countries were chosen.

On the other hand, my colleague believe that a background step is needed when multiple scenarios in the feature file has same GIVEN clause and we can move such a STEP to single BACKGROUND clause in the beginning of the feature file.

In this instance, what do you advise? Given the critical nature of the scenario, the vagueness of the way the test is written.

2 Answers 2

4

In the end, it runs to personal preference on how to right things. As you said,

a background step is needed when multiple scenarios in the feature file has same GIVEN clause and we can move such a STEP to single BACKGROUND clause in the beginning of the feature file.

So, instead of:

Scenario: X
  Given there is a user for the country "<country>"
  When the user searches...
  ....

Scenario: Y
  Given there is a user for the country "<country>"
  When the user creates...
  ....

You will get:

Background: there is a user for the country "<country>"

Scenario: X
  When the user searches...
  ....

Scenario: Y
  When the user creates...
  ....

Since the goal of the Gherkin language is to communicate the behavior of your system, in the end, it doesn't make a big difference, since humans can simply keep in mind one piece of information ("there is a user...").

If you break down the different behaviors of your system in different .feature files, you will end up with just a few scenarios per file, with no much more than one piece of info that you would keep in the background, so... no much difference for a human to read.

1

Background is generally used for similar setup for all scenarios in the feature file. If its the same scenario run for multiple countries, to me it makes more sense to have those countries in a table outline if your framework allows for it. Although, I don't see why you can't test all the country codes if it is critical.

Feature: Phone Number Country Codes
This test covers country codes for the 10 countries listed below.

Scenario Outline: the correct country codes appear when you enter a telephone number
Given country '<country>'
When I enter a telephone number
Then it has the '<expectedCode>' county code

Examples:
| country      | expectedCode |
| UnitedStates | 1            | 
| China        | 86           |
1
  • I agree. I think I will do that. Thank you so much
    – fypnlp
    Mar 5 at 18:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.