Handy Gherkin Cook Book

With all the buzz around Gherkin, have you found yourself “in a pickle” trying to figure out just what it is? Or how it relates to software testing?

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

What is BDD?

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

What is Cucumber?

Cucumber is an open-source software testing tool that supports BDD. It offers a way to write tests that anybody can understand, regardless of their technical knowledge.

Now we all know Cucumber supports simple English text then why we need a separate language — Gherkins. The answer lies in the concept of the Behavior Driven Development.

A successful project needs people from different community like developers, project managers, product owners, and testers while developing test scripts and they do not belong from the same background. Here conceptualizing the risk of not using the common language for test script. This was the evolution point for Gherkins.

Let’s cook the Gherkin in an easy and delicious way:

What is Gherkin?

Gherkin is a language that is being used to define test cases 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 everybody.

Gherkin can be written in two ways Imperative and Declarative Gherkins.

Imperative Gherkin:

· Imperative scenarios tend to be long with lots of navigating to pages, filling in fields, and pressing buttons.

· Imperative Gherkin can greatly dilute the power of Cucumber.

· It is easy to write but is costly and painful in the long term.

· Imperative Gherkin creates recurring Given-When-Then chains, which can become pages long.

· Sometimes it is very complex and difficult to convert to test script.

User Login example in Imperative Gherkin:

> Enter username into username text box

> Enter password into password text box

> Click on sign-in button

> Verify that username is displayed after login

> Verify that welcome message is displayed

> Verify that sign-out link is displayed

> Verify that user has access to his profile

Declarative Gherkins:

· Declarative Gherkin is only specifying (or declaring) what needs to be accomplished, not the details of how it is done.

· In Declarative Gherkin it’s better to think about the features not the UI so that if UI will be modified in future then also no effect on our test cases as a result.

· In this approach, better to avoid writing many test cases related to UI.

· These are easily converted to test script.

User Login example in Declarative Gherkin:

> Using user credentials to login

> Click on sign-in button

> Verify that user is signed in successfully

Gherkin Keywords:

Gherkin uses a set of special keywords to give structure and meaning to executable specifications.

The primary keywords are:

1. Feature
2. Background
3. Scenario
4. Given
5. When
6. Then
7. And
8. But
9. ‘ * ‘

There are a few secondary keywords as well:

1. “”” (Doc Strings)
2. | (Data Tables)
3. @ (Tags)
4. # (Comments)

Example of Gherkin Scenario for Login:

On the surface, Gherkin looks easy — just write some steps to describe the desired behavior. Though writing good Gherkins are not easy at first. Here are four rules that will help us to write readable, automatable, scalable Gherkin.

Gherkin Rules:

1. Gherkin’s Golden Rule

Gherkin’s Golden Rule is simple, we have to treat other readers as we would want us to be treated. More specifically, needs to write test cases in a way so that everyone can intuitively understand them. Good Gherkin should improve team collaboration by clarifying behaviors we want to develop. When Gherkin is tough for others to read, teams can not develop good product.

2. The cardinal rule of BDD

The cardinal rule of BDD is a one-to-one rule. One scenario should cover exactly one single, independent feature.

3. The unique example rule

Sometimes, less is more, so better not to include unnecessary examples. Testing “all the things” might sound tempting, but that wastes precious time. Instead, we have to test the most important things, and avoid testing duplicate things.

4. The good grammar rule

Writing is definitely an art and to express language matters. Behavior scenarios are meant to be readable and expressive. Steps are meant to be reusable. Poor grammar, misspellings, and inconsistent phrasing can ruin the benefits of behavior specification. Scenarios can become confusing, and team members could use steps out of context.

One of the biggest language problems with Gherkin is an inconsistent point of view. We can write steps using first-person perspective (“I, me, my”) or third-person perspective (“the user …”). While I strongly favor third-person perspective for Gherkin steps.

Wrapping Up

Gherkin and Cucumber combination always is a great choice which reduces confusion and rework without digging into technical aspects. With the best practices and following the Golden Rules, we can write Gherkins easily in a productive way. Happy to share and have fun writing good Gherkin.