Cucumber Basics

Before moving on to Cucumber we should know about What is Behaviour Driven Development (BDD)?

Behaviour-driven development (BDD) is an Agile software development process That encourages collaboration and closes the gap between developers, QA, and non-technical or business participants in a software project. BDD describes the overall behaviour of the system and customer focused.

In BDD, users (business analysts, product owners) first write scenarios or acceptance tests that describe the behaviour of the system from the customer’s perspective, for review and sign-off by the product owners before developers write their codes. To achieve this we use the Cucumber testing tool.

Cucumber reads executable specifications written in plain text and validates that the software does what those specifications say. The specifications consist of multiple examples or scenarios. For ex:

Scenario/ Example : add x and y

Given I have a variable called x

And I have a variable called y

When I add x and y

Then I display the result

In order for Cucumber to understand the scenarios, they must follow some basic syntax rules, called Gherkin. The above example is written in Gherkin.

What is Gherkin?

• Gherkin is a language cucumber uses to define test cases
• It is a human readable plain text.
• Non-technical
• This can be used for executable specifications, automated tests and living documentation.

Gherkin uses a set of special keywords to give structure and meaning to executable specifications. Each keyword can be written in many spoken languages, here we write in English language.

Gherkin Keywords

• Feature
• Rule
• Example or Scenario
• Given, When, Then, And, But for steps (or *)
• Background
• Scenario Outline

There are few secondary keywords

• “”” (Doc Strings)
• | (Data tables)
• @ (Tags)
• # (Comments)

Feature

Every *.feature file conventionally consists of a single feature. Lines starting with the keyword Feature:. A feature usually contains a list of scenarios.You can write anything you want up until the first scenario, which starts with Scenario: or Example:.

You can use tags to group features and scenarios together, independent of your file and directory structure.

Example:

Feature: Serve drink

In order to earn money

Customers should be able to

buy drinks at all times

Scenario: Buy last drink

Given there are 1 cup of drink left in the machine

And I have deposited 1 dollar

When I press the drink button

Then I should be served a drink

Scenario

Each feature can have one or more scenarios. It starts with Scenario: keyword. Each scenario can have one or more steps.

Scenario: Adding and employee to the company data

Given I am logged in as Admin

When I try to add a new employee

Then I should see “Employee added successfully.”

Given

Given is a precondition when you have worked with use cases. Avoid talking about user interactions in givens.

Scenario: Setup the database

Given the database is clean.

When

When is used to describe a key action the user performs. Only have a single When step per Scenario, if you need more, then we have to split the Scenario into multiple.

Scenario: Carol post his own blog

Given I am logged in as Carol

When I try to post “Cucumber Lesson”

Then

Then is an outcome which belongs to the feature. It can be a value or message or a report or a user interface.

Scenario: Add two numbers

Given I have a calculator

When I add 6 and 9

Then the result should be 15

And, But

If you have several Given, When or Then steps you can write

Scenario: Multiple Givens

Given one thing

And another thing

And yet another thing

When I open my eyes

Then I see something

Then I don’t see something else

Scenario: Multiple Givens

Given one thing

And another thing

And yet another thing

When I open my eyes

Then I see something

But I don’t see something else

Gherkin also supports using an asterisk (*) in place of any of the normal step keywords. This can be helpful when you have some steps that are effectively a list of things, so you can express it more like bullet points where otherwise the natural language of And etc might not read so elegantly.

Scenario: Multiple Givens

Given one thing

* another thing

* another thing

* yet another thing

When I open my eyes

Then I see something

But I don’t see something else

Background

A Background is much like a scenario containing a number of steps. But it runs before each and every scenario for a feature in which it is defined. It is used to define a step or series of steps that are common to all the tests in the feature file.

For example, to purchase a product in an Ecommerce website first you have to navigate to the login page and then you have to give the username and password to login. And then only we can add a product in a basket and make payments.

These steps are common for all the tests. So instead of writing them again and again for all tests, we can move it under the Background keyword.

Background: User Logged In

Given I navigate to the login page

When I have given username and password

Then I should be logged in

Scenario: Search a product and add the product in the basket

Given I have search for a watch

When I have add that watch by clicking basket icon

Then User basket should display with the added item

Scenario: Search another product and add the product in the basket

Given I have search for a jewellery

When I have add that jewellery by clicking basket icon

Then User basket should display with the added item

Scenario Outline

Scenario: Add two numbers

Given I have a calculator

When I add 5 and 2

Then the result should be 7

Scenario: Add two numbers

Given I have a calculator

When I add 6 and 9

Then the result should be 15

Without doing it repetitive by using scenario outline we do it as follow:

Feature: Calculator

As a user

I want to use a calculator to add numbers

So that I don’t need to add myself

Scenario Outline: Add two numbers <num1> & <num2>

Given I have a calculator

When I add <num1> and <num2>

Then the result should be <total>

Examples:

| num1 | num2 | total |

| -2 | 3 | 1 |

| 10 | 15 | 25 |

| 99 | -99 | 0 |

| -1 | -10 | -11 |

Without hard-coding this values we can do it as follow:

Examples:

| Parameter_Name1 | Parameter_Name2 |

| Value-1 | Value-2 |

| Value-X | Value-Y |