Understanding Gherkins - The Language of Behavior Driven Development (BDD) Part 1

Gherkins are also small cucumbers used for pickling!

However, this article is about Gherkins in the context of Software engineering domain where Gherkins takes a different -and powerful -meaning.Gherkins is a domain-specific language (DSL) used to define test cases for Behavior Driven Development (BDD).

Gherkins use plain English syntax, bringing Developers, Testers, and Stakeholders onto the same page, promoting true collaboration and transparency.

Here are several popular BDD tools and frameworks that use Gherkins to automate tests

•  Cucumber (for Java, JavaScript, Ruby, etc.),

• SpecFlow (for .NET applications),

• Behave (for Python projects)

These tools interpret Gherkin files and map each step to corresponding code that actually performs the automated checks behind the scenes.

In this article, Gherkins has been demonstrated with a Cucumber project.

Why Do We Need Gherkins?

Traditionally, test cases are written in procedure driven style and are documented in test management tools, while the automation code that executes those tests are written separately in development environments. As a result:

• Business analysts and testers work with written test cases.

• Developers and automation engineers work with the code.

  
  

This often creates a communication gap between technical and nontechnical teams, increasing the redundant work, and even missed requirements.

Gherkin solves this problem by:

• Allowing test cases to be written in plain English (e.g.: In a .feature file in a Cucumber project)

• Mapping the test cases directly to automated scripts in BDD frameworks (e.g. each .feature file is mapped to a StepDefinition in a Cucumber project)

• Providing a common language that is both human-readable & contains mapped code lines that can be directly executed by the testing tools.

Key Features of Gherkin Syntax

Gherkin scenarios are typically structured using the Given-When-Then format.

The feature file (.feature) consists of keywords - Feature, Scenario, Scenario Outline, Given, When, Then, And, But

• Feature: Describes functionality of the application.

• Scenario: Represents a specific example of a feature’s behavior.

• Scenario Outline: Represents feature’s behavior that can be executed with multiple datasets.

• Given: Describes the initial state or preconditions.

• When: Specifies the event or action performed by the user/system.

• Then: States the expected outcome or result after the action.

• And is used in addition to previous steps and represents positive statements.

• But is used in addition to previous steps and represents negative statements.

  Some Best Practices for Writing Gherkins Syntax

1.     One scenario, One behavior. Avoid covering multiple conditions in a single scenario.

2.     Use “And,” “But” sparingly keeping the scenarios clean and readable.

3.     Gherkins should be easy to understand, usually written in present tense and from third person’s point of view.

4.     Emphasize on ‘re-usable steps with consistent phrasing’, as it helps reduce maintenance efforts.

5.     Use tags like @Smoke, @Negative, @ Positive to help group and filter Scenarios for Test Runs.

6.     Focus should be on the behavior & not on how its implemented.

Example of a Gherkin Scenario:

Let us translate a ‘traditional test’ case of performing a search on Google page ‘into Gherkins’

Traditional test case for ‘Google Search’:

1.     Navigate to the google home page (https://www.google.com/)

2.     On the landing page, enter the keywords in the search bar and press Enter Key

3.     Links related to the entered keywords should be displayed to the user

Gherkins for ‘Google Search’:

A user can map each of the traditional test case word by word as seen in Option 1 or can restrict to Gherkins best practices as seen in Option 2

Option 1

Feature: Google Search

Scenario: Search keywords at the search bar

Given User is on Google home page

When user enters keywords in the search bar

And presses the enter Key

Then links related to the keyword are displayed on the page

Following image shows the Gherkins for Option 1 in a .feature file

Below image shows the mapped Option1StepDefinition.java file

Please note here that, In Step Definition file, there are no ‘And’ and ‘But’.

And and But are listed as Given/When/Then i.e, the keyword they appear after.

So, the statement ‘And presses the enter key’ statement is changed to @When (“presses the enter Key”) as it was following a when statement, making it two @When statements and so on.

Option 2

Feature: Google Search

Scenario: Search keywords at the search bar

Given User is on Google home page

When user enters keywords in the search bar

Then links related to the keyword are displayed on the page

Following image shows the Gherkins for Option 2 in a .feature file

Below image shows the mapped Option2StepDefinition.java file

The question arises, which one is the correct approach when adopting Gherkins for real-world automation?

 Should the Gherkins have detailed steps like Option 1 or should follow limited 'And' , 'But' like Option 2 (Unlike Option1StepDefinition.java, the Option2StepDefinition.java has only one @When step, where the action of pressing key will be bundled with the action of the user entering keywords in search bar).

Well, both the approaches are fine but the recommended one would be - Option 2.

The reason being that the step focuses on the behavior and not on how it is implemented (pressing enter is just a technical detail, not important for understanding the behavior). So, unless an action has functional importance, it can be kept abstract.

However, Option 2 must be considered when

•        the action is meaningful on its own/ is of functional importance

•       The step could be used in other Tests as well.

Let us learn more concepts in following articles.