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 in detail of implementation.

This serves two purposes; documenting user scenarios and writing 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 system.

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

Rules for using Gherkin:

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

Gherkin Syntax

Gherkin is line oriented language like Python and YAML. Each line called step, 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 starts with # 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, file should have extension .feature and each feature file should have only ONE feature. Feature starts with keyword Feature: and after that space and whatever next to that is name of the feature. You can keep writing free text and that will be description of feature until first occurrence of text Scenario.

In previous example,  feature name is, “Verify if I can send email or not” . Description of feature is “This is some information about this scenarios 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 end of line. Cucumber process each line as it but 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 contains, background, scenario outline and example depending on 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 contains few steps as scenario but only difference is that it runs before each scenario as pre-condition.

Best Practices

  • Do not add complicated steps in 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 scenarios is set of steps knows as combination of Givens, Whens and Thens. As I have already mentioned that cucumber ignore these keyword while actually running code but as a user, we should not.

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

Given

The solo purpose of Given is to put the system in a well known state before user interaction come into 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 fixture.

When

When step is to define action performed by 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 outcome after 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 tabular format and use column name as 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 variable in programming. Code execute 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 consist of three parts; Keyword, string or regular expression equivalent to step and code block. To understand the step definition, refer following. We will go in detail once we start implementing real code.

 

Gherkin

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

To generate these steps you need run following command.

$cucumber <filename>.feature – –d

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

Summary

So far we learned about BDD and 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.

liked us?

Archives