Mastering Gherkin for Software Testing: A Step-by-Step Guide

Hari Mahesh

When we hear the word Gherkin, two things come to our mind: the first one is Cucumber, and the second one is BDD (Behavior-Driven Development). All three of these are closely connected. We will be discussing Gherkin and its details today in this article.

What is Gherkin?

Before we jump into Gherkin, we should first discuss Behavior-Driven Development (BDD), as Gherkin is mainly associated with it. BDD is a software development approach that has evolved from Test Driven Development (TDD). Which primarily bridges the communication gap between business stakeholders and technical teams. It ensures collaboration between developers, QA, and business participants. So, in BDD, it’s crucial to understand the software functionality clearly across all levels. Read here the differences between TDD and BDD.

These features should be simple, well structured, and written in natural language, which helps the developers, the QA, and the business team to understand thoroughly. So, to write in that simplistic way, Gherkin is used. Read here about the top 5 BDD tools.

Gherkin is one of the most popular domain-specific languages for writing use cases for a particular software functionality in plain English. Though we say plain English, it has some associated rigid syntax. Cucumber is the BDD tool that maintains the official Gherkin standards. Cucumber reads the Gherkin tests and executes the code related to that line.

Why Gherkin?

There are many benefits of using Gherkin. We can list it down quickly:

• Describes the use cases in a way that is easy to read and understand.
• It allows every stakeholder, like business analysts, managers, developers, and testers, to be involved in understanding the use case and contribute.
• It creates a solid base for the tests.
• The Gherkin file acts as simple documentation for the underlying scripts.
• In terms of automation, the Gherkin script makes it easy to reuse the code.
• Anyone with no experience in coding can understand the automation scripts, which means the review of scenarios happens faster, leading to faster time-to-market.

We have understood Gherkin and its advantages. Now, let’s see how we can write a Gherkin file.

The Gherkin’s Syntax

The 3 Major keywords in Gherkin are – Given, When, and Then. There are a few other keywords, but these are the main ones. So, let’s see what these keywords are for.

Given

This keyword sets the precondition for the scenario. It introduces the functionality which we are going to explain. So, this will be the initial step. So, with this step, we will interact with the application under test.

Example: Given User is logged into the application

When

This keyword describes our main actions in that use case. It can also be a particular event the use case is examining.

Example: When User clicks the Save button

Then

This keyword describes the outcome or the result. The results will be based on the condition mentioned in the “When” keyword.

Example: Then User is displayed with a confirmation message

And

This keyword is used to connect multiple conditions or multiple results. If the scenario has various conditions to be added or multiple results are the outcome, then this keyword is used.

Example: And User profile is updated

But

This keyword often indicates negative scenarios or an alternate outcome. However, this keyword is significantly less used; it can be replaced with “And” to make the scenario more readable and consistent.

Gherkin’s Keyword

Apart from the syntax keywords, there are other terms that we commonly use in Cucumber. So, let’s go through those and understand them better.

• Feature: The Gherkin file starts with this keyword. This is preceded by a text that describes the particular use case we are testing. The Gherkin file name also will have an extension feature like “<somename>.feature“. Sometimes, the feature contains a title and a description.
• Scenario: We can define a scenario as a test case. Feature is a use case, and the scenario is the test cases generated from that use case. A feature may contain multiple scenarios. The scenario includes a series of steps that start with the keyword “Given“. The scenario begins with the keyword “Scenario“, followed by the description of that scenario.
• Background: Here, we can define steps common to all the scenarios in a feature file. The primary purpose of this keyword is to eliminate the repetition in every scenario. So we can group all these steps to this keyword and execute them before each scenario starts. It’s similar to the “Before” hook in most automation frameworks.

Feature: User Login
  As a registered user,
  I want to log in with my username and password,
  So that I can access my account dashboard.
Background: User is on the Login Page
  Given the user has navigated to the login page
Scenario: Successful Login with Valid Credentials
  Given the user has entered a valid username and password
  When the user clicks on the login button
  Then the user should be redirected to the dashboard
Scenario: Unsuccessful Login with Invalid Credentials
  Given the user has entered an invalid username or password
  When the user clicks on the login button
  Then the user should see an error message

BDD 2.0

There is a widespread misconception that BDD means Cucumber and Gherkin language, which is invalid. BDD is a process, Cucumber is a tool, and Gherkin is a language used by Cucumber that supports BDD. Though we mentioned the positive side of BDD, there are many disadvantages, too. You can read more about the drawbacks here. That’s where BDD 2.0, or Specific Driven Development (SDD), came into the picture.

In SDD, we do not use Gherkin, which uses a specific format. Gherkin is only useful if we write the code for each step in the feature file, which complicates the total system. This was changed in SDD. Read here about TDD vs. SDD vs. BDD.

open url "https://www.amazon.com"
click "Sign In"
enter stored value "email" into "email"
click "Continue"
enter stored value "password" into "password"
click "Login"
enter "Men's Printed Shirt" roughly to the left of "search"
click "Search"
click on image from stored value "Men's Printed Shirt" with less than "10" % discrepancy
click "Add to Cart"
click "Cart"
click "Checkout"

testRigor has the simplicity of the test scripts as a primary advantage. The elements are identified by their name as they appear on the UI, not with any XPath/CSS locators. Thanks to testRigor’s intelligent generative AI. As you can see, there is no need to write separate programming for each step or anything; just write the test steps in plain English, and you are done. You also use the recorder feature and generate the test steps automatically in plain English as per your UI interaction.

The test cases are ultra-stable and reduce maintenance effort to a great extent through self-healing. Have a look at the other incredible features here.

Wrapping Up

As the slogan “early-to-market” is a common term now, and development processes like BDD are streamlined to support that, we still feel we need more pace or speed; that is where BDD 2.0 or SDD pitches in.

With SDD, the time to market reduces exponentially, as we can develop, test, and deliver the product and services in the same sprint. Tools that support SDD, such as testRigor, make the quick delivery of a high-quality end product possible within budget and with minimum effort and time.

“We spent so much time on maintenance when using Selenium, and we spend nearly zero time with maintenance using testRigor.”

Keith Powe VP Of Engineering - IDT