Cucumber Best Practices to follow for efficient BDD Testing

What is Cucumber Tool?

Cucumber is a testing tool that supports behavior-driven development (BDD). 

• BDD bridges the gap between the stakeholders and technical team through a common platform. 
• Gherkin is used as the language using which the test cases are written. It is a simple format and can also be read and modified by a non-technical user. 

In BDD, “Given-When-And-Then-But” is the proposed approach for writing test cases. Listed below is an example of BDD.

Feature:  I want to login into the site with valid data and Invalid data

   Background:

       Given I navigate to the Website

   Scenario: Login as a new sign-up user with valid data

           When I entered the user name

           And I entered the password

           And click on the sign-in button

           Then validate user successfully logged-in

   But log-in button is not present      

      Scenario: Login as a new sign-up user with invalid data

           When I entered an invalid user name

           And I entered the password

           And click on the sign-in button

           Then Error message should display

   But Re-login option be available

What are Gherkin Keywords

In the above example, there are many keywords, and every keyword has its own meaning and purpose.

Let’s explain each keyword with respect to the above example.

• Feature Keyword: The feature file starts with the keyword Feature. Under feature, you can mention the feature name which is to be tested, as seen below

I want to login into the site with valid data and Invalid data

• Scenario Keyword: There can be more than one scenario under one feature file, and each scenario starts with the keyword Scenario, followed by the scenario name. In the below example, we can see there are two scenarios.

Scenario: Login as a sign-up user with valid data

Scenario: Login as a sign-up user with invalid data

• Given Keyword: Given keyword is normally used when we have to give some pre-condition in our test case as seen in the example below

Given User is on the home page of the site or

Given User is on the  Log-in page of the site.

• When Keyword: When the keyword is used to perform some action, as depicted in the example below

When the user enters an email or

When the User clicks on the "Log in" button

• And Keyword: There is no annotation for AND keyword. It is used to connect two statements and provides the logical AND condition between any two statements. AND can be used in combination with GIVEN, WHEN and THEN statements and used for positive assertion

When I entered my "username"

And I entered “password”

• Then Keyword: Then Keyword is used for the final outcome or for validation 

Then validate the user successfully logged in Or

Then an Error message should display

• But Keyword: But the keyword is used to represent negative assertions in addition to the previous statement.
• Background Keyword: If there is any repetitive step that is going to be used in every test case. We just add the repetitive step under Keyword Background. Step keep under Background would be run before every test case.

Background: Given I navigate to the Website

Cucumber Best Practices for Effective Testing

1. Write test scenarios as early as possible

It’s a good practice if we are ready to write test scenarios before creating test code. Developing scenarios early helps you define software behavior and understand possible problems in a better way. Once a scenario is ready and reviewed by team members who agree with it, we can start implementing the functionality. This will save time and effort and take away uncertainty later, during the development, or when your team will run acceptance tests.

2. Features and Scenarios

A feature is a product functionality, whereas a scenario is the specification of behavior.

Feature file:

1. Feature file should be specific to the page, meaning if you have to cover the login scenario we should create a “login.feature”
2. A single feature file can contain multiple scenarios
3. Avoid mixing feature files
4. Every feature should be ready to be executed alone

Scenario:

To describe the scenarios, Gherkin keywords are used: Given, When, Then, But and And During writing the scenario we have to make sure we should use keywords in an appropriate way. 

See below an example of a poorly written scenario

Scenario: As an existing user, I want to log in successfully

Given the user is on the Home page

When the user clicks on the login link on Home Page

And the user can see the login screen

And the user enters his username and password

And the user is able to click on the login button

Then the user is logged in successfully

And the successful login message is displayed

A better way to write the same above scenario with fewer lines is as follows. It is best to avoid details that don’t contribute much.

Scenario: As an existing user, I want to log in successfully.

Given the user is on the Home page

When the user navigates to the Login page

And the user enters the username and password

Then the successful login message is displayed

3. Use Background

It is always the best practice to put steps that are repeated in every scenario into the Background. The background step is run before every scenario.

Ensure that you don’t put too many steps in there, as your scenarios may become hard to understand. Given below is an example.

Feature:  I want to login into the site with valid and invalid data

   Background:

       Given I navigate to the Website

   Scenario: Login as a new sign-up user with valid data

       When I entered a valid credential

           | email| validpassword |

           | qatubeupdate@yopmail.com | 12345         |

       When the user clicks on the sign-in button

       Then Validate the title after login

   Scenario: Login with invalid data by entering an invalid password

       When I entered an invalid credential

           | email | invalidpassword |

           | qatubeupdate@yopmail.com | 123456    |

       When the user clicks on the sign-in button

 Then Error message should display

           | errormessage |

           | Authentication failed |

4. Try to re-use step definitions

It’s best practice to reuse the step definitions that you frequently use in various scenarios. For example, “Given: user navigate to the Website”  can be one common step that we need in every scenario. So we can reuse this step.

Reusing the steps improves the maintainability, just in case there are any changes, you need to update in a single step.

Ensure the language/words are consistent if you want to re-use the step. In the below example, the steps are the same but the words (casing) are not consistent.

 Click and click are considered different because of the casing. 

Given (“Click on ‘Sign In link’ on the Home Page”)

Given (“click on ‘Sign In link’ on the Home Page”)

5. Use a Data Table

It’s recommended to use Data Table to store the data. You can give data as parameters within the step but once you have a large set of data. It is not feasible to relinquish all data as parameters. It’s better to use a data table once you have a large set of data.

A data table is used to inject data at the step level. The below example illustrates the steps for “I entered valid credential”

Feature:  I want to login into the site with valid and invalid data

Background:

Given I navigate to the Website

@SmokeTest

Scenario: Login as a new sign-up user with valid data

When I entered valid credential

| email                    | validpassword |title|

| qatubeupdate1@yopmail.com | 12345         | Home   |

| qatubeupdate2@yopmail.com | 12345         | Home   |

| qatubeupdate3@yopmail.com | 12345         | Home   |

| qatubeupdate4@yopmail.com | 12345         | Home   |

When User click on sign-in button

Then Validate the title after login

6. Use a Scenario outline

Scenario outline injects the info at the scenario level rather than the step level. Scenario outline followed by the keyword.

Feature:  I want to login into the site with valid and invalid data

Scenario Outline: Login Validation

       Given I navigate to the Website

       When I enter "<email>" and "<validpassword>" to login Page

       And User click on sign-in button

       Then Validate the "<title>" after login

       Example:

           | email | validpassword |title|

           | qatubeupdate@yopmail.com | 12345 | Home   |

7. Use of Tags

Using tags could be the best practice once we want to run a bunch of test cases. There will be the case that we don’t want to execute all test cases in a single run or we would like to execute a group of the test cases. So best practice is to configure the test case by putting Tags on it. They are marked with @ followed by some text.

For example, a group of smoke test cases and sanity tests is created. You can put a tag over the scenario like @SmokeTest, @SanityTest, @RegressionTest, etc.

Feature:  I want to login into the site with valid and invalid data

   Background:

       Given I navigate to the Website

   @SmokeTest

   Scenario: Login as a new sign-up user with valid data

       When I entered a valid credential

           | email                    | validpassword |

           | qatubeupdate@yopmail.com | 12345         |

       When a user clicks on sign-in button

       Then Validate the title after login

  @SanityTest

   Scenario: Login with invalid data by entering an invalid password

       When I entered an invalid credential

           | email | invalidpassword |

           | qatubeupdate@yopmail.com | 123456 |

       When the user clicks on the sign-in button

       Then Error message should display

           | errormessage  |

           | Authentication failed |

8. Map your scenario with the requirement

It’s a best practice to provide the required number (#Jira story id) after the scenario in the feature file. If any scenario fails then tracking the failed requirement from the execution report becomes easier (See below test case execution screenshot)

For example, in lines #6, and #14  of the code below, the required number is specified for better tracking.

Feature:  I want to login into the site with valid and invalid data

   Background:

       Given I navigate to the Website

   @SmokeTest

   Scenario: Login as a new sign-up user with valid data: QA-135, QA-156

       When I entered a valid credential

           | email | validpassword |

           | qatubeupdate@yopmail.com | 123451 |

       When the user clicks on the sign-in button

       Then Validate the title after login

  @SanityTest

   Scenario: Login with invalid data by entering the invalid password: QA-569, QA-281

       When I entered an invalid credential

           | email | invalidpassword |

           | qatubeupdate@yopmail.com | 123456 |

       When the user clicks on the sign-in button

       Then Error message should display

           | errormessage |

           | Authentication failed |

Test Result: The result of the above test can be seen below, where in the Smoke Test fails while the Sanity Test passes. Here, using the JIRA Story ID can be used to track the failed tests and debug.

9. Avoid Conjunctive Steps

While writing the feature, it is best to avoid conjunctive steps. When you find a Cucumber step that contains two actions in conjunction with an “and”, you should break it into two steps keeping one action per step. This makes the steps more modular and increases reusability. This is not a general rule but a best practice.

10. Write in a declarative way, not Imperative

Scenarios should be written in a way the user would describe them. Beware of scenarios that only describe clicking links and entering data in form fields, or of steps that contain code. This is not a feature description. Declarative features are realistic, compendious, and contain highly maintainable steps.

Example of Declarative Scenario:

Scenario: Verify login

Given user navigate to the Website

When user enters credentials

Then the user clicks on the sign-in button

Then validate the title after login

Example of Imperative Scenario:

Scenario: Verify login

Given I navigate to the Website

When I enter “username”

When I enter “password”

When I check the “Remember me” check box

Then the user clicks on the sign-in button

Then Validate the title after login

11. Rules for writing Scenarios in Cucumber

Test scenarios should be written in a way that is easy to understand and clear for every team member. Below are some common recommendations 

• Proper use of correct grammar and spelling 
• Step definitions should not end with periods, commas, and other punctuation marks
• Avoid jargon
• Use correct punctuation

When dealing with behavior-driven automation, there are a ton of rules that you can use as guiding principles, the main core thing we have to keep in mind is one should properly use keywords GIVEN, WHEN, and THEN. Remember all the above points when we write test cases using the BDD framework.

Today, many organizations prefer using the Cucumber framework as it is easy to read and understand test cases. Cloud testing products like BrowserStack support Cucumber with Selenium and Cypress. 

Run Selenium and Cypress Test on Real Device for Free