1. Home
  2. OpKey Help
  3. 18. Working with BDD (Gherkin Stories)
  4. 18.1 Gherkin Syntax

18.1 Gherkin Syntax

Working with Gherkin

After successfully login into OpKey Web, select the appropriate Project in which you want to create a Gherkin .

You will be navigated to the screen having as shown.

You can mark the “Don’t show me again” checkbox as checked if you do not wish to view this notification again.

Click “End Tour” to proceed with the process of creating a Gherkin file.

How to create a Gherkin Feature File?

Method 1

After clicking on “End Tour” , you may “Click to Create New Artifact.Select Gherkin .

The Gherkin  text will appear highlighted.

Click on the highlighted icon to create a New Gherkin Feature file. A pop up window will get open as shown

The fields marked with * are mandatory. Enter the Name of the Gherkin Feature. You can also enter the Description.Click OK.

Method 2

Go to Project Workspace > Select the root Folder > Click Create New file icon  > Select Gherkin Feature .

A Gherkin Feature file will be created in the root Folder of the project Workspace.

You may rename the Gherkin Feature accordingly.

Method 3

Right click on root folder > select Create New > select ‘Gherkin Feature .

A Gherkin Feature file will be created in the root Folder of the project Workspace.

The Gherkin Feature window will open up as shown:

BDD specifies that business analysts and developers should collaborate in this area and should specify behavior in terms of user stories, which are each explicitly written down in a dedicated document.

This format is referred to as the Gherkin language, which has syntax similar to the above example

Gherkin Feature

It is a Business Readable, Domain Specific Language that lets you describe software’s behavior without detailing how that behavior is implemented. Gherkin serves two purposes i.e. Documentation and automated tests. It also has a bonus feature, it converse back to developer/testers/business analysts using real, human language telling them what code they should write.

Gherkin Syntax

Gherkin is a line-oriented language that uses indentation to define structure. Line endings terminate statements and either spaces or tabs may be used for indentation. Most lines in Gherkin start with a special keyword.

The above snap shows one of the examples of Gherkin syntax. Following are the detailed meaning of keywords used in Gherkin:

Feature

A feature usually contains a list of scenarios, where user can write whatever he wants till the first scenario, which starts with Scenario:

For instance:

gherkin-02

Steps:

Features consist of steps, also known as Givens, Whens and Thens. Gherkin doesn’t distinguish between these three kinds of steps. However, it is strongly recommended that usage of these words should be for their purpose, to get into the BDD mindset.

002

Given:

The purpose of givens is to put the system in a known state before the user (or external system) starts interacting with the system. If you have worked with use cases, givens are your preconditions.

For Instance:

003

When:

Its purpose is to describe the key action the user performs.

For Instance:

Interact with a web page

0004

Then:

Its purpose is to observe outcomes. The observations should be related to the business value/benefit in your feature description and should inspect the outcome of the system (a report, user interface, message, and command output)

For Instance:

004

And:

If a story contains several ‘Given’.

For Instance:

005

In the above example, using ‘And’ the same scenario can be written as:

006

Backgrounds:

Backgrounds allow adding some context to all scenarios in a single feature. A Background is like an untitled scenario, containing a number of steps. The difference is when it is run: the background is run before each of your scenarios.

For Instance:

7

In the above example, upon execution, steps before will execute first, followed by the steps in scenario.

Scenarios:

Scenario is one of the core Gherkin structures. Every scenario starts with the Scenario: keyword (or localized one), followed by an optional scenario title. Each feature can have one or more scenarios, and every scenario consists of one or more steps.

For Instance:

8

Scenario Outlines:

The Scenario outline steps provide a template which is never directly run. It is basically used for iterating the scenarios.

For Instance:

10

The above example shows the same scenario, which is to be validated with different values now consider the following instance using Scenario Outlines:

11

In the above example, it is run once for each row in the Examples section beneath it (not counting the first row of column headers). The Scenario Outline uses placeholders, which are contained within <> in the Scenario Outline’s steps. For example:

12

The placeholder acts like a variable. It is replaced with a real value from the Examples: table row, where the text between the placeholder angle brackets matches that of the table column header. The value substituted for the placeholder changes with each subsequent run of the Scenario Outline, until the end of the Examples table is reached.

Upon execution, during first iteration of the above scenario outline, the placeholders gets replaced by the values of the first row of Examples table i.e.

The scenario that is actually run is:

13

And subsequently in the next iteration, the values of the second row of the Examples tables get replaced.

Was this article helpful to you? Yes No