Gherkin Made Easy: From Plain Words to Dynamic Tests

QA automation can be done with test cases written using Gherkin language and also with test cases using plain words. Both approaches work; but the test cases written in Gherkin often stand out as clearer and more powerful than the traditional test cases. QA testers use Gherkin because it’s easier to read, understand and maintain. In this blog, we will explore why Gherkin is unique and why it’s widely sought after by the testing world.

So, what’s exactly Gherkin?

In plain words, Gherkin is a simple language used to write test cases.  Gherkin is a straightforward, clear, user-friendly, structured, uncomplicated human-readable language and is used in Behavior-Driven Development (BDD) with tools like Cucumber to describe the software behavior. It uses plain everyday words such as GIVEN, WHEN, THEN and AND in the test cases to describe or state how the system should behave.

Gherkin or the ‘Living Documentation’

In the testing field, the traditional test cases get outdated when the requirements change. But Gherkin adapts easily to the changed requirements or features. In simpler words, Gherkin test cases are up to date as per the latest changes of the software and is known as living documentation. It is considered 'living' because it updates with the software, always mirroring the current state of the system.

Let’s have a look at the basic syntax/keywords of Gherkin

There is a set of keywords that form the skeleton of a good test case such as Feature, Background, Scenario, Given, When, Then, And, Scenario Outline. These syntaxes ensure a structure. Feature: it’s like a blueprint of the feature of the software application we are going to test such as ‘User Login’, ‘User Logout’, ‘User Registration’. Background: it’s like a step or action that runs before each scenario. Scenario: it’s a testcase that has a single test; we are testing a particular condition only. Some examples are ‘user tries to login with correct credentials’, ‘user tries the logout button’.

Given: it can be described as the precondition or the current state before the user does any action such as ‘Given the user is in the homepage, ‘Given the user is in the registration page’. When: it is the action done by the user such as ‘When the user clicks the Register button’, ‘When the user clicks the Login button’. Then: it is the response or outcome of the action done by the user such as ‘Then the user is redirected to the Register page’, “then the user navigates to the Login page’. And: it is used to add more steps or conditions; also, can be considered as a bridge to connect multiple steps. Scenario Outline: it is used to test a scenario with multiple data inputs, such as different sets of login credentials, different set of registration combinations etc.

The below examples are perfect snapshots of the above Gherkin syntaxes that I used in my DsAlgo practice project. These are created in feature folder under src/test/resources/

All the above screenshots are from my DsAlgo practice project.

Why Gherkin is powerful?

As we mentioned earlier, Gherkin is used in Behavior-Driven Development to describe the software behavior. By using the Gherkin syntaxes, it keeps the focus on the expected behavior. Also, Gherkin improves the communication, collaboration between all stakeholders, no matter technical or non-technical, which in turn increases the productivity as a team to develop the expected product/application. With clear requirements, the team as a whole can aim a single goal – the final product. Another advantage of using Gherkin is that it creates room for less errors due to clear instructions or requirements.

Finally, how does this turn into a real test in the automated world? Let me walk you through the steps to connect the Gherkin test cases to the automated tests. Cucumber is a testing framework that supports BDD to run the tests written in Gherkin. The Gherkin scenarios are written in the 'feature files' with a .feature extension and are usually kept under src/test/resources/features/ as shown below.

Tags are used in feature files before each scenario to select or group the scenarios. Some examples are @sanity, @smoke, @regression, @high, @wip, @skip etc. The below screenshot shows how a tag looks in a feature file.

Step definitions are the link that connect these feature files into automation code. In short, when we execute the Gherkin scenarios, Cucumber will look for a matching automation code in the stepDefinitions. We create a package named 'stepDefinitions' under src/test/java/ and this is where the actual code is written. Since the codes are written in java, the step definition files are given a .java extension.

You might be wondering how we actually run the scenarios. And that is where the 'runner' comes to the picture. In every project, there will be runner which is considered as the starting point. The runner tells Cucumber what to run and it also can run only specific scenarios by using tags. Below is the screenshot of a runner.

The runner points Cucumber to the feature files and to the package with step definitions and selects the scenarios to run using the specified tags. Glue is used to tell where the step definitions are and to match the Given/When/Then/And in the feature files to match with their respective code in step definitions. The plugins generate the required reports.

Conclusion Gherkin is not just a language in automated testing; it is an integral part in automation to increase the quality and functionality of the final software application. Gherkin provides the foundation that connect plain test cases to real automation. Gherkin keeps the whole team on the same page when it comes to automated testing. If you are a beginner in automation, try writing the test cases with Gherkin and experience the power of Gherkin.