Code & QA

Gherkin Tutorial

Introduction

Young green cucumber used for pickle called Gherkin. That’s why, to understand cucumber standard, we need to first understand Gherkin language. It is a business readable, domain-specific language that helps you describing business behavior without going into detail of implementation.

This serves two purposes; documenting user scenarios and writing an automated test. It is easy to write user behavior so anyone can understand your business need and at the same time developer can use these statements to automate the behavior of the system.

Gherkin is based on TreeTop Grammar which exists in 37+ languages thus you can write your gherkin in 37+ spoken languages.

Rules for using Gherkin:

  • Single Gherkin source file should have a description of the single feature.
  • the source file should have the .feature extension.

Gherkin Syntax

Gherkin is a line-oriented language like Python and YAML. Each line called step and starts with keyword and end of the line terminates the step. Tab or space (preferred) are used for indentation.

Comments can be added anywhere but start with a # sign. Parser splits cucumber into features, scenarios, and steps. It reads each line after removing Gherkin’s keywords (given, when, then etc.).

Typical Gherkin steps look like:

Feature: Verify if I can send email or not

This is some information about this scenarios

and collective report.

Scenario: compose email and send with attachment.

Given I have an email application logged in

And I open compose email

When I draft recipient

Feature

As mentioned above, the file should have extension .feature and each feature file should have only ONE feature. The feature starts with keyword Feature: and after that add a space and whatever next to that is the name of the feature. You can keep writing free text and that will be the description of the feature until the first occurrence of text Scenario.

In the previous example,  feature name is, “Verify if I can send an email or not”. Description of the feature is “This is some information about this scenario and collective report.”.

Each feature file can have multiple scenarios and each scenario starts with Scenario: followed by scenario name. Each scenario consists of steps and each step must start with one the keyword Given, When, Then, But or And and terminates with the end of the line. Cucumber process each line as it but the user should use them differently to understand scenario clearly.

Scenario: compose email and send with attachment.

Given I have an email application logged in

And I open compose email

When I draft recipient

Along with scenarios, feature file may contain, background, scenario outline an example depending on the situation.

Scenario: compose email and send with attachment.

Given I have an email application logged in

And I open compose email

When I draft recipient

Background

Background allows you to add some context to the scenario. It may contain few steps as a scenario but the only difference is that it runs before each scenario as pre-condition.

Best Practices

  • Do not add complicated steps in the background. Make it simple and straight and put only high-level info. Avoid any detailed info in this to avoid any confusion.
  • Keep background as short as possible because this runs every time before running scenarios.
  • Try to make a smooth flow in your background and scenario to make reading in straight order.

 

Given When Then

A cucumber scenario is set of steps knows as the combination of Givens, When, and Then. As I have already mentioned that cucumber ignores these keywords while actually running code but as a user, we should not.

Keeping Behavior Driven Development (BDD) mindset while writing steps will help to solve the purpose. We will talk in detail about each type of steps.

Given

The sole purpose of Given is to put the system in a well-known state before user interaction comes into the picture. Always avoid writing user interactions in Given steps. Consider that Given is “Precondition” step.

Example

Given user have all data for form

Given user logged in to the system etc.

Note: If you are Ruby on Rails user, it is recommended that use Given with multiple values in table to avoid putting in the fixture.

When

When the step is to define action performed by the user.

Example

When user submit form

When I delete subscriber from database

Note: One Scenario should have only ONE When step.

Then

The purpose of Then is to see the outcome after the action in when step.  You should verify only observable changes.

Example

Then subscribers should be removed from subscribers page

Then form should be submitted with acknowledge number.

And & But

You may have multiple given when or Then.

Scenario: use of And with But

Given I am logged in

Given I did some setup

Given I do another thing

When I take some action

Then I should see successful message

Then I should not see full detail

This can make your scenario more simple and detailed with help of And & But.

Scenario: use of And with But

Given I am logged in

And I did some setup

And I do another thing

When I take some action

Then I should see successful message

But I should not see full detail

Scenario Outline

It is repetitive and cumbersome to write same scenarios again and again with different values.

Scenario: Find if subtraction is working Given there are 10 apples

When I give 3 bananas to my friend

Then I should have 7 bananas

Scenario: Find if subtraction is working

Given there are 20 apples

When I give 5 bananas to my friend

Then I should have 15 bananas

You can re-write above two scenarios into one scenario by using ‘Scenario Outlin5e’. You need to use replace Scenario with ‘Scenario Outline’. Convert all data values into a tabular format and use the column name as a reference using < > sign. For example above two scenarios need to re-write like this;

Scenario Outline: Find if subtraction is working Given there are <total> apples

When I give <donated> bananas to my friend

Then I should have <remaining> bananas

Example:

|total|donated|remaining|

|10    |3           |7             |

|20    |5               |15            |

This is very helpful if you are testing a field or form with various combinations of values. This is possible by placeholder and you can identify placeholder by text surrounded by <>. Placeholder work as a variable in programming. Code execute a number of times based on available rows in ‘Example’ keyword. Each time placeholder replaced by values given in corresponding column Name.

Step Definition

While execution, for each step cucumber, looks for matching step definition. Step definition consists of three parts; Keyword, string or regular expression equivalent to step and code block. To understand the step definition, refer following. We will go into detail once we start implementing the real code.

 

Gherkin

Cucumber again does not care for a keyword, but expression is very important. \d+ take any digit for the same line and keep or repeating if you are using a table to supply values.

To generate these steps you need run following command.

$cucumber <filename>.feature – –d

This command does the dry run for cucumber and verifies if we have all step definition created or not. You can copy and paste the output into your step_definition folder/file and start implementing actual code.

Summary

So far we learned about BDD and the basic structure of cucumber steps using Gherkin. We learned Scenario and Scenario outline with example and learned when to use these. We also learned in short about Given/When/Then and what rule should we follow while writing. We saw how to generate step definition using – –dryrun command. I have separate tutorials where we will learn how to write and implement code in Java/Ruby.