Question

When defining scenarios in Gherkin sometimes there is no clear distinction between Given and When steps, i.e. there is no active interaction with the system from the user and the purpose of the validation is to verify how the system should look under certain circumstances.

Consider the following:

Scenario: Show current balance
Given user is on account page
Then user should see his balance

vs

Scenario: Show current balance
When user goes to account page
Then user should see his balance

I am not sure I would always use the second variant. If I have multiple scenarios sharing the context "user is on account page" and some of them have additional user actions while others don't, then it seems to me it should be valid to keep "user in account page" as a Given step even though it may lack "When" for some scenarios. Is this a valid approach?

Was it helpful?

Solution

Formally and technically Cucumber/SpecFlow doesn't require you to write a When-step or rather Given/When/Then's are just executed in the order they are written in the scenario. In that regard you don't need a When-step.

But, as Andy Waite wrote about, the When-step shows on the action or event that your system takes from the "Setup" to get to the new state that you verifies in the Then-step. In that regard a When-step should be present in every test (as you wrote: what are we testing otherwise).

That leaves your final comment; what about verifying just the setup (Given the system is started, Then the database is clean as a naïve example). In such scenarios the When-step could be skipped.

So, as always, it comes down to readability and understanding. Scenarios are written to make our thoughts about the systems behavior concrete and clear. Use the form that optimize for understanding and learning about the behavior in question.

Without thinking too hard on this I would probably guess that the general advice is to always use a When-step that makes the event or behavior very apparent and clear. I would shy away from implicit and hidden behavior when possible.

I hope this helps.

OTHER TIPS

Generally a scenario consists of 3 parts:

  • Setup (the Given)
  • Action (the When)
  • Verification (the Then)

Sometimes the setup isn't required (or it's implicit). But I can't think of any situations in which you wouldn't need an action and verification.

Agree with Andy + Marcus here but I've a few comments that may be of use.

  1. Gherkin feature files should act as living documentation for the behaviour of your system. For this reason scenarios should provide enough detail to convey to a developer and other project stakeholders (product owner, testers etc) the business rules that embody that feature.

    I think your question may have arisen from not considering this business rule end to end when articulating the scenario. I'd have to ask someone the question , what is a balance? Therefore I feel you may need a step to at least convey the concept - that before a user can look at their balance, they have to have one.

    Scenario: Show current balance
      Given I have a balance
       When I go to my account page
       Then I should see my balance
    
  2. It's important to set system state (i.e. any 'Given' step) to allow you to clearly test that the system is working correctly - otherwise how are you going to determine that the balance is actually correct? You may wish to make this more explicit by specifying some arguments:

    Scenario: Show current balance
      Given my balance is £10
       When I go to my account page
       Then I should see my balance as £10
    
  3. I'm not sure which BDD framework you are using but I use Behat which allows you to map more than one Gherkin step to a step definition. I.e

    user is on account page
    user goes to account page
    

    can both map to a step definition which navigates a user to a page. The system behaviour is the same, the only reason to distinguish between the two, as you have, would be to make your scenarios more readable.

To my understanding when you write a scenario the are 3 steps that are needed.

  1. A state that your application should be in at the begining.
  2. What the user has to do to reach a certain state.
  3. The outcome/input of the user's action i.e the end point of your scenario.

So the scenario will be something like :

Given the user is on the profile page
When the user goes to the balance page
Then the user should see their balance

The profile page will be where the user can click a button or link to acess their balance.

Then have a background :

Given the user is logged in
And the user has a balance
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top