In this post, we are going to talk about the industry wide most discussed, a new language that testing is going to speak – The Gherkin Language. Gherkin language is business readable, domain specific language that helps all the stakeholders to understand about the software without going into the technical details of the software.
The beauty of Gherkin is that it helps in the documentation of the functionality of the application in plain English text. Which can be even understand by a person without any technical knowledge and secondly it provide skeleton for writing test automation scripts by converting the steps into a automation function.
Gherkin file is stored with .feature extension and a single gherkin file gives you a description of the particular feature of the application.
Gherkin is a line-oriented language that uses indentation to define structure.Either spaces or tabs may be used for indentation. One line should be treated as one step and mostly it starts with a keyword .
a line that starts with a hash sign (#) is treated as comment
Steps are defined with Given-When-Then statements
Let’s take the example given into the previous post. The below scenario is about returning of the faulty computer that Jeff has brought.
Feature: Refund item Scenario: Jeff returns a faulty computer Given: Jeff has bought a computer for $900 And: he has a receipt When: he returns the computer Then:Jeff should be refunded $900
The text highlighted in blue are the keywords that we use in writing the feature file. We will go in detail one by one on all these keywords.
- Feature – This keyword refers to description of the functionality of application for which feature file is written. In the above example, the text after Feature says ‘Refund Item’ which suggest us we are going to have different scenarios for refund functionality of application
Please note: A single feature file can have multiple scenarios.
- Scenario – This keyword refers to high level classification of the requirement grouped to test the intended functionality of application. In the above example, the text after Scenario says‘Jeff returns a faulty computer’which suggest us that we are going to test refund item functionality for this scenario.
- Given – This keyword is used to put system in known state before the user start interacting with the system. In short we can say Given is set of pre-conditions that needs to be fulfilled before we write our use cases. In the above example, to test the refund item functionality for the faulty conditions the pre-condition (or given statement) says Jeff should brought the computer first and he should have receipt for processing the refunds.
- When – This keyword is used to describe the user action which he/she perform. In above example the action performed by Jeff is he returns the computer. So return is the user action for Jeff here.
- Then – This keyword is used to describe outcome of the user action which he/she perform. In above example when Jeff returns the computer the then statements says that the amount is refunded which is outcome of the when statement.
- And – Supposed in your particular scenario you need to write Given, When,Then multiple times ,which can lead to confusion to other people who might be reading these files. To avoid this we can use the And keyword instead of multiple Given, When and Then. In above example the And refers to the part of the Given statement which means if both the condition satisfy then only we can move to When statement.
Apart from these keywords there are 2 more keywords that are used into the Gherkin
- Scenario outline – In below two scenario we can see that only difference is on the data part whereas scenario seems to be same.So copying and pasting scenarios will become tedious and repetitive.
Scenario: Eat 5 out of 12 Given there are 12 cucumbers When I eat 5 cucumbers Then I should have 7 cucumbers
Scenario: Eat 5 out of 20 Given there are 20 cucumbers When I eat 5 cucumbers Then I should have 15 cucumbers
To avoid this we can use the ‘Scenario Outline’ concept through the use of a template with placeholders:
Scenario Outline: Eating Given there are <start> cucumbers When I eat <eat> cucumbers Then I should have <left> cucumbers Examples: | start | eat | left | | 12 | 5 | 7 | | 20 | 5 | 15 |
Please note : The Scenario outline steps provide a template which is never directly run. A Scenario Outline is run once for each row in the Examples section beneath it (not counting the first row of column headers).
- Tags – Tags helps us to organize the features, scenario and scenario outlines.The syntax for using the tags is “@TagName” where TagName is any name you want to give to your scenario, feature.Also we can tell Cucumber what scenario needs to be executed on the basis of tag (We will discuss more about it in details in later article).
Please note: If we provide a tag name to a feature file it will be by default valid for the scenario, scenario outline that is present in that feature file.
Read more about Gherkin syntax at cucumber.io