3 reasons we like Gherkin test cases

To provide a little background, let me offer a brief introduction to the Gherkin Language (not the pickle). Gherkin was introduced over 10 years ago as part of the Behavior Driven Development (BDD) process. BDD builds on Test Driven Development (TDD) but is more user or behavior-focused, and introduced the Gherkin language.

Gherkin uses human-readable plain text, keywords, and formatting to help bridge the gap between non-technical and technical audiences. The Gherkin language can be used for both user stories created by product owners and test cases created by developers and QA engineers. I will only be covering test cases in this article.

In short, Gherkin is a language that uses a simple syntax to describe the behavior of software in plain-text format, using keywords to define features, scenarios, and steps.

1. Structure and consistency

The first reason we like the Gherkin language for test cases is its structure and consistency. Regardless of who the writer is or how much experience they have, everyone includes the same keywords in the same format. With our widely distributed teams in different states, countries, and continents, structure wins.

It is hard enough in today’s world to be on the same page when the team sits on the same floor — but when teams are in different time zones with different cultures and languages, structure provides the glue, and Gherkin is the interface, or the contract, between all parties. Structure also allows test cases to be more easily maintained and updated. Unstructured test cases are hard to read and harder to maintain.

Here is an example of a Gherkin test case:

Feature: Account login

  Scenario: Registered user signs in successfully
    Given a registered user is on the login page
    When they enter a valid email and password
    And they select "Sign in"
    Then they are taken to their dashboard
    But no password is stored in the browser

The keywords used above:

• Feature: — describes a high-level feature of the software.
• Scenario: — describes a specific scenario or test case.
• Given, When, Then — steps used to describe the conditions, actions, and expected outcomes of a scenario.
• And, But — allow more conditions to be added.

These keywords, combined with human-readable plain text, make test cases easy to understand regardless of the audience’s technical abilities. This allows all stakeholders to create and consume the Gherkin language. In best practice, test cases should be created before any code is generated. In the real world, I have found that high-level test cases created by developers before, and detailed test cases created by QA engineers after, is also effective.

2. Ease of automation

The second reason we like Gherkin is the ease of automation the structure allows. Because of the keywords and consistency, automation becomes much easier. In fact, full software frameworks have been developed for the Gherkin language.

Cucumber is a framework that interprets Gherkin and produces code written in Java to automate the test case. There is also SpecFlow, which is more .NET-focused. Both frameworks are open source and can be used in conjunction with larger testing frameworks such as Playwright, Selenium, or Cypress to give you a complete platform for creating automation.

In regression testing, automation becomes vitally important to verify functionality in a timely and cost-effective manner. At Nebo Consultants, we believe this also enables automation to be created and maintained effectively by remote, offshore teams. Gherkin combined with these frameworks creates very maintainable code.

3. Better communication and living documentation

The third reason we like Gherkin is that it improves communication across all stakeholders and serves as living documentation, providing a clear and concise representation of software behavior.

Gherkin can be consumed by your support teams, implementation teams, and others to better understand the expected behavior of your software. Using one language to describe software behavior from idea to support is a powerful benefit for anyone who develops software. With our teams distributed throughout the world, Gherkin not only breaks down technical barriers but also helps with language and cultural barriers as well.

---

I hope I have sparked your interest in the Gherkin language. Please let us know if you have any questions — and what you think of Gherkin.