Gherkin: How many preconditions should a scenario have? - automated-tests

Question

I am new to Gherkin and BDD.
We are doing BDD regression tests with Squish.
Our application is very complex - similar to a flight simulator.
Now I ask myself how to write the tests in Gherkin.
As we have a large number of variables as preconditions to a certain situation I would normally put a lot of
Given some precondition
And some other precondition
into my tests.
My natural feeling is that I should avoid this because it would make things unnecessarily complex.
Is there a rule of thumb for how many preconditions there should be?
Should I try to reduce it to only one?

Answer 1

The general rule is to have as few as possible while still making the tests useful. How many that is will depend on the audience for your scenarios.
If you are using gherkin scenarios for actual BDD (Behaviour Driven Development) then you will have to write the scenarios in such a way that your stakeholders can make sense of them. If this means that you have to write many Given, And, And steps then that is the way it has to be. If it means that you can put several of these steps into one more general set up step then that is better.
If you are using the Gherkin scenarios only as a way of automating tests then do whatever is good for your dev team. The rule about having as few steps as possible comes from trying to make sure everyone, technical and non technical understands what is meant by the scenario (i.e. that they are as clear AND concise as possible. If it is only the technical team that needs to understand it then as above you can use many steps if that is what is necessary for your team to understand it, or you can use fewer steps that contain more code.
For your case of having a very complex system to get into the correct state for testing, I wouldn't be worried about having may set up steps, so long as the scenarios you end up with are clear and as short as possible. There wouldn't be any point in having a smaller neater scenario that no one really understood without looking at the code!

Answer 2

When you are writing scenarios, you can make the code behind the steps do whatever you need to set the application in a state that is needed for testing. Thre is a pretty good article explaining the point here.
I find that if you can be more descriptive in your steps, then your tests will make more sense when you need to go back to reference them. If your steps are just Given, click, click, click, Then .. you can easily lose track of the point of the test. Your tests should be about system behaviors not step by step instructions for using the system.
So as far as preconditions are concerned. You need to do whatever it takes to get the application in the state that you wish to test.

Answer 3

Gherkin is a Business Readable, Domain Specific Language created especially for behavior descriptions.
Gherkin serves two purposes: serving as your project’s documentation and automated tests. Gherkin’s grammar is defined in the Treetop grammar that is part of the Cucumber codebase.
To understand Gherkin in a better way, please take a look at simple scenario mentioned below:
Feature: As a existing facebook user, I am able to post a birthday greeting on any other existing user's facebook page
Scenario: Verify that Joe Joseph can post a birthday greeting on Sam Joseph's facebook page
Given Joe Joseph is an existing facebook user
Given Sam Joseph is an existing facebook user
Given Joe Joseph is on login page of facebook
Given Joe Joseph logs into his facebook account
When Joe Joseph opens Sam Joseph's facebook page
And Joe Joseph writes "Happy Birthday Sam" on Sam Joseph's facebook page
And Joe Joseph clicks on Post button
Then Joe Joseph verifies that "Happy Birthday Sam" is successfully posted on Sam Joseph's facebook page
In the above scenario, all the statements that starts with "Given" are my preconditions.
So, as far as precondictions are concerned, you can use as many preconditions which is required for the test.

Answer 4

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 More here
From above statement my understanding is. You don't need to add precondition every time as who is using scenario knows how to write and understand Gherkin language.
Here is example:
When I take login as system admin
And I click on new user
And I enter new user details
Then new user is created successful
Here I don't need to mention where I am and other precondition like URL opened or not ?
First precondition is URL opened or not.
Given I opened URL "http://www.stackoverflow.com"
And I enter system admin details
And I click on new user
When I enter new user details
Then new user is created successfully
Second Condition New User Details form have all the required field. This can be separate scenario.
Goal is tell business and team that we are testing this scenario. It is not test case. You don't need to create tons of document for testing purpose.

Answer 5

Like YAML or Python, Gherkin is a line-oriented language that uses indentation to define structure. Line endings terminate statements (called steps) and either spaces or tabs may be used for indentation. Finally, most lines in Gherkin start with a special keyword:
Sample
Feature: Some terse yet descriptive text of what is desired
In order to realize a named business value
As an explicit system actor
I want to gain some beneficial outcome which furthers the goal
Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too
Scenario: A different situation
...
The parser divides the input into features, scenarios and steps. Let’s walk through the above example:
Feature: Some terse yet descriptive text of what is desired starts the feature and gives it a title.
Scenario: Some determinable business situation starts the scenario, and contains a description of the scenario.
The next 7 lines are the scenario steps, each of which is matched to a regular expression defined elsewhere.
Scenario: A different situation starts the next scenario, and so on.
When you’re executing the feature, the trailing portion of each step (after keywords like Given, And, When, etc) is matched to a regular expression
Also note, if you have precondition like Given I opened URL "http://www.stackoverflow.com" as mentioned my #Boston. It is recomended to use it as Background.
Example
Feature: This is test feature
Background: background scenario
Given I opened URL "http://www.stackoverflow.com"
Scenario: access first senario
Given: I should see this
...
Scenario: access second scenario
Given: I should see that
...
The background will execute before every scenario.
Reference:
https://github.com/cucumber/cucumber/wiki/Gherkin