In this article, you will learn some of the best practices that can be followed to write effective Gherkin scenarios that make your test automation more meaningful and powerful. These practices once followed yields massive benefits along with the Three-Amigos Sessions.
What is the Gherkin Language?
The answer is simple. It’s just simple English put together to form a meaningful case. It is written in Given-When-Then format.
There are few annotations/syntax in which Gherkins can be achieved:
- Given – Used to describe the initial context of the system
- When – Used to describe an event or an action
- Then – Used to describe an expected outcome or result
- And – Used to combine more than one event or outcome
- But – Used to write the negative outcome (occasionally used)
In BDD, the scenarios are drafted in a file called “Feature” file. The feature files will contain all the scenarios used to develop a feature. In general, a Feature file will look like the below structure:
Feature: Sample Feature / Requirement # Feature Title In order to <receive benefit> # Feature Injection / Description As a <role> I want to <goal/desire> Scenario: Example Scenario # Scenario Title Given one thing # Describes the Initial Context add another thing # Combines Steps When I open my eyes # Describes an Action Then I should see something # Describes positive Outcome But I should not be seeing something else # Describes a negative Outcome
Apart from writing the Gherkin scenarios with GWT’s, we need to adopt several other artifacts that give more sense to the features/scenarios we write. Let’s see those now.
Comments allow the author of the feature file to add additional information for the benefit of developers and testers. It will start with a hashtag “#”.
# Comments Feature: Login into XXXX Application # Story number - 1234 # Author: Giridhar Rajkumar # Drafted on 04 Oct 2019 Scenario: Successful Login using Valid Credentials # Prerequisites # 1. The user should be knowing the credentials # 2. The environment should not have SSO enabled Given I am in the Login Page When I try to login with valid credentials Then I should be successfully logged in And navigated to Home Page
There are many instances in which the scenarios might contain or share common steps. Instead of duplicating those steps we can put it under the Background section.
Tips: In this case, the steps given in the Background will be executed for every scenario.
# Background Feature: Login into XXXX Application Background: Given I am in the Login Page Scenario: Successful Login Using Valid Credentails When I try to login with valid credentials Then I should be successfully logged in And navigated to Home Page Scenario: Error Message while using Invalid Credentials When I try to login with invalid credentials Then I should be shown an error message And should stay in Login Page
The Scenario Outline is highly reusable in Gherkin.
Let’s consider the above example in the Background section. We see that both scenarios are doing the same actions, but with different credential types. It is generally parameterized using Examples. Rows in the table represent the parameter values. These values are replaced with angular brackets “< >” later in the scenarios.
# Scenario Outlines Feature: Login into XXXX Application Scenario Outline: Login using different types of credentials Given I am in the Login Page When I try to login with <type> credentials Then I should be <outcome> Examples: |type |outcome | |valid |successfully logged in| |invalid|shown error message |
Tags are the best way to categorize the scenarios of our needs. It can be used to execute a specific set of tests. They are 100% customizable, meaning you can use any word as tags. It will always start with @ character before the scenario as given below.
Tips: Tags can be used in both Scenario and Feature level.
# Tags @LoginFeature Feature: Login into XXXX Application @smoke @regression @sprint001 @manual Scenario Outline: Login using different types of credentials Given I am in the Login Page When I try to login with <type> credentials Then I should be <outcome> Examples: |type |outcome | |valid |successfully logged in| |invalid|shown error message |
Gherkin Golden Rules
- In a Scenario, there should be only ONE Given, When and Then steps.
- Maximum usage of two And steps are allowed.
- Make sure your Scenario has a maximum of 5 steps and not more than that. In case, if it is exceeding, try to split it into two different scenarios.
- Make sure the scenarios are not UI/UX centric always.
Three Common Mistakes While Writing Gherkin Scenarios
- Writing scripts in first person instead of a third person.
- Describing every UI/UX action instead of a functionality.
- Using absolute values like locators instead of configurable values.
Hence, these are the best practices we need to adopt for writing effective Gherkin Scenarios that are appropriate to all types of stakeholders and make the automated tests powerful.
Comments21 2 comments