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
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?Answer1:
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.Answer2:
Agree with Andy + Marcus here but I've a few comments that may be of use.<ol><li>
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</li> <li>
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</li> <li>
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.</li> </ol>Answer3:
Generally a scenario consists of 3 parts:<ul><li>Setup (the Given)</li> <li>Action (the When)</li> <li>Verification (the Then)</li> </ul>
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.Answer4:
To my understanding when you write a scenario the are 3 steps that are needed.<ol><li>A state that your application should be in at the begining.</li> <li>What the user has to do to reach a certain state.</li> <li>The outcome/input of the user's action i.e the end point of your scenario.</li> </ol>
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