Gherkin is the format for cucumber specifications. It is a domain specific language which helps you to describe business behavior without the need to go into detail of implementation. This text acts as documentation and skeleton of your automated tests. Gherkin is based on TreeTop Grammar which exists in 37+ languages. Therefore you can write your gherkin in 37+ spoken languages.
This script serves two primary purposes:
- Documents user scenarios
- Writing an automated test (BDD)
In this Gherkin tutorial, you will learn
- What is Gherkin?
- Why Gherkin?
- Gherkin Syntax
- Important Terms used in Gherkin
- Gherkin Example
- Best practices of using Gherkin
- Advantage and Disadvantages of Gherkin
The need for Gherkin can be easily explained by following images
Gherkin is line-oriented language just like YAML and Python. Each line called step and starts with keyword and end of the terminals with a stop. Tab or space are used for the indentation.
In this script, a comment can be added anywhere you want, but it should start with a # sign. It read each line after removing Ghrekin's keywords as given, when, then, etc.
Typical Gherkin steps look like:
Gherkin Scripts: connects the human concept of cause and effect to the software concept of input/process/output.
Feature: Title of the Scenario Given [Preconditions or Initial Context] When [Event or Trigger] Then [Expected output]
A Gherkin document has an extension .feature and simply just a test file with a fancy extension. Cucumber reads Gherkin document and executes a test to validate that the software behaves as per the Gherkin cucumber syntax.
- Scenario Outline Examples
The naming convention is used for feature name. However, there is no set rules in Cucumber about names.
The file should have extension .feature and each feature file should have only one feature. The feature keyword being with the Feature: and after that add, a space and name of the feature will be written.
Each feature file may have multiple scenarios, and each scenario starts with Scenario: followed by scenario name.
Background keyword helps you to add some context to the scenario. It can contain some steps of the scenario, but the only difference is that it should be run before each scenario.
The use of Given keyword is to put the system in a familiar state before the user starts interacting with the system. However, you can omit writing user interactions in Given steps if Given in the "Precondition" step.
Given - a test step that defines the 'context Given I am on "/."
When the step is to define action performed by the user.
A When - a test step that defines the 'action' performed When I perform "Sign In."
The use of 'then' keyword is to see the outcome after the action in when step. However, you can only verify noticeable changes.
Then - test step that defines the 'outcome.' Then I should see "Welcome Tom."
And & But
You may have multiple given when or Then.
A But - additional test step which defines the 'action' 'outcome.' But I should see "Welcome Tom."
Given, When, Then, and, but are test steps. You can use them interchangeably. The interpreter doesn't display any error. However, they will surely not make any 'sense' when read.
Given The login page is opening When I input username, password and click the Login button Then I am on the Homepage
Feature: Login functionality of social networking site Facebook. Given: I am a facebook user. When: I enter username as username. And I enter the password as the password Then I should be redirected to the home page of facebook
The scenario mentioned above is of a feature called user login.
All the words written in bold are Gherkin keywords.
Gherkin will analyze each step written in the step definition file. Therefore, the steps are given in the feature file and the step definition file should match.
Feature: User Authentication Background: Given the user is already registered to the website Scenario: Given the user is on the login page When the user inputs the correct email address And the user inputs the correct password And the user clicks the Login button Then the user should be authenticated And the user should be redirected to their dashboard And the user should be presented with a success message
- Each scenario should execute separately
- Every feature should able to be executed along
- Steps information should be shown independently
- Connect your Scenario's with your requirements
- Keep a complete track of what scenarios should be included in a requirement document
- Create modular and easy to understand steps
- Try to combine all your common scenarios
- Gherkin is simple enough for non-programmers to understand
- Programmers can use it as a very solid base to start their tests
- It makes User Stories easier to digest
- Gherkin script can easily understand by business executives and developers
- Targets the business requirements
- A significant proportion of the functional specifications is written as user stories
- You don't need to be expert to understand the small Gherkin command set
- Gherkin links acceptance tests directly to automated tests
- Style of writing tests cases are easier to reuse code in other tests
- It requires a high level of business engagement and collaborations
- May not work well in all scenarios
- Poorly written tests can easily increase test-maintenance cost
- Gherkin is the format for cucumber specifications
- Gherkin is line-oriented language just like YAML and Python
- Gherkin Scripts connects the human concept of cause and effect to the software concept of input/process and output
- Feature, Background, Scenario, Given, When, Then, And But are importantly used in Gherkin
- In Gherkin cucumber, each scenario should execute separately
- The biggest advantage of Gherkin is simple enough for non-programmers to understand
- It may not work well in all type of scenarios