What Is Gherkin + How Do You Write Gherkin Tests?

There are many options available to teams when it comes to how to write and test software. How do you determine which syntax to use and what testing solution is right for you? In this post, we’re going to explore the use of Gherkin and Gherkin tests. We’ll cover the syntax, how to write a test, and address the pros and cons.

These options can be a good choice under the right circumstances, but there are certain considerations to keep in mind before you jump in, especially when you also factor in the test automation process. 

Before we discuss what Gherkin is and how to write Gherkin tests, there are a few things that we need to cover first. It’s important to understand the role that Behavior-Driven Development (BDD) plays and how this practice, Cucumber, and Gherkin all work together.

What is BBD?

Behavior-Driven Development (BDD) is a development method that encourages communication between teams. This collaborative approach brings the business and the technical aspects of projects together. This method allows teams to better communicate on requirements, detect problems early on, and maintain software over time with ease.

Teams that use BBD have a couple of goals. The first is to make sure that the requirements can be understood by the entire team. Then the teams can focus on preventing possible issues, rather than putting out fires if they’re found later. Often this means that less re-working is required. 

Simply we can describe this development in two phases. Discovery and testing.  

First, teams figure out what they don’t know BEFORE they start working. Then, they have a better understanding of how to stay on track and be more productive. 

When it comes to testing, the process of thinking about these tests starts before development even begins. Tests are written to drive the implementation and the final product. 

What is Cucumber?

Cucumber is an open-source software testing tool that supports BBD. (Behavior-Driven Development). It works with Gherkin because the Gherkin syntax structures plain text so that it can be read by the tool.

Cucumber reads Gherkin tests and validates that the code performs as it should. It does this by working through Gherkin scenarios and steps. (More on this below). Cucumber will then create a report showing of each step and scenario was successful or if it fails. 

What is Gherkin?

Gherkin is a language that developers use to define tests in Cucumber. Since this language uses plain English, it’s meant to describe use cases for a software system in a way that can be read and understood by almost anyone.

This syntax promotes behavior-driven development because it allows developers, managers, business analysts and other parties involved to understand the requirements of the project and the life-cycle. 

The language makes it easy to create simple documentation of the code that’s being written.  Gherkin also provides scripts for test automation and supports dozens of languages. 

whitepaper

Behavior-driven development. Who needs Gherkin?

How to write Gherkin tests

To write Gherkin tests, you first need to understand some of the keywords used, and what they do in practice. Here’s a list of the most common keywords in Gherkin syntax.

• Feature
• Rule
• Example
• Given, When, Then, And, But
• Background
• Scenario Outline

Each keyword is critical to the process of writing a great Gherkin test. Now, let’s take a closer look at these keywords and how to use them to write Gherkin tests.

Feature

Gherkin documents start with this keyword, followed by text that provides a description. More simply put, the feature is a description of what the software is supposed to do. This keyword is also used to group scenarios together.

This isn’t really for testing purposes, but it allows you to add documentation on requirements and business rules. The description section ends when you start a new line with one of the other keywords such as scenario outline, example or rule. 

Descriptions

If needed, free-form descriptions can also be written underneath the keywords mentioned above, as long as none of your lines start with a keyword.

Rule

The rule keyword is used to represent one business rule that needs to be included. This provides context for a feature. These “rules” should have more than one scenario to show the rule and may have a background section. (Detailed below).

Gherkin Steps

Next, let’s take a look at some of the steps in Gherkin tests. These are Given, When, Then, And, or But.

Given

Given steps set the scene for the scenario. In most cases, these steps describe something that took place in the past. This gives the system context before a user starts interacting with it. For this reason you should not cover user interactions in this step. Think about what you include in this step as preconditions.

Note: You can have more than one Given step. 

When

When steps are action steps. They describe an event. Examples would be an event triggered by another system or a user interacting with it. It’s recommended that you only have one when step for each scenario.

Then

Then steps are outcome steps. This is where you describe what you want the system to do so that it can be compared to how the software actually performs in practice. This should be something that you can actually see as a result, like a message or report.

And, But

When you have several of one of the step types listed above you can use and or but. This helps keep your documentation organized and readable.

Background

As mentioned above, the background allows you to add even more context to the scenarios in a feature. This is where you can have more than one given step, as needed.

Note: There can only be one background step for each feature. If you need more background steps, you’ll have to create different feature files. 

Scenario Outline

The scenario outline contains an examples section. These steps are read like a template. The scenario outline runes once for each row of the example section except for the header row.

Pros and Cons of Using Gherkin

Now that you know how to write a Gherkin test, you may be wondering how to determine if this is the right option for your team. The truth is that there are both advantages and disadvantages that come with using Gherkin and Cucumber. Let’s take a closer look at a few of them.

Gherkin is simple

At its core, Gherkin is easy for both developers and business executives to understand. In a sense, it’s “non-technical”, making collaboration across teams easier.

Focuses on project requirements

Gherkin syntax and this type of testing really targets the project and business requirements. This ensures a development process built with the user experience in mind.

Re-using code

The way these tests are written makes it easier to re-use parts of the code of other tests. This can add up, saving time, money and resources.

Not for all projects

Gherkin + Cucumber is not ideal for all project types. Short projects that will require a lot of testing may be delayed using this method. While BBD does have a time and place, this way of thinking and the implementation of these tests can slow projects down.

It requires a lot of engagement

This could be a pro or a con, depending on your team’s development methodology. As mentioned earlier, Gherkin and Cucumber go hand in hand with behavior-driven development. This means it requires your team to constantly work collaboratively, which may not always be a fit for your project.

Potential Expense

Though these tests can be easier to write, a poorly written test can result in a lot of extra time and money wasted if tests need to be re-written. Unless developers understand Gherkin and Cucumber very well, this type of testing can be a huge financial risk

The Future of Gherkin

Here at Functionize, we believe moving away from Gherkin is the future and will bring better benefits. Gherkin is one way that people write out test plans, but that’s not where the process ends. Developers still have to write out test scripts. This process can waste a lot of time that developers could be spending elsewhere.

Gherkin is a good first step to incorporate non-technical people into automation testing. But our customers turn to our ALP because we 'cut out the middle-man' of having to script Selenium and make test creation easy. 

Wrapping Up

Gherkin and Cucumber can be a good choice when you need everyone on the team to be clued in without digging into technical aspects. However, down the line, this combination can make test automation more complicated than it needs to be.

The choice is yours, but before you choose a syntax and solution, consider the pros and cons carefully. The most important thing is that you and your team get the right tools for your development projects. 

However, our view is that Gherkin is simply too inflexible and hard to learn. Our solution is our recently-released NLP Engine. This allows you to write tests as a series of steps in plain English. 

This blog explored what Gherkin testing is, how to write Gherkin tests and the pros and cons of using this syntax. We hope that this has given you insight on the best language and testing options for your next project.