Should Gherkin scenario always have When step?

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.