Cucumber Best Practices to follow for efficient BDD Testing

This blog was originally published at https://www.browserstack.com/guide/cucumber-best-practices-for-testing

— By Kailash Pathak

What is Cucumber Tool?

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

• BDD bridges the gap between the stakeholders and the 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

Cucumber Best Practices for Effective testing?

1. Write test scenarios as early as possible

It’s 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

Feature file:

1. Feature file should be specific to the page e.g for login we’ve login. feature and after login, if we’ve got to verify the Home page content we’ll create a HomePage.feature file.
2. In a single feature file, there’ll be multiple scenarios
3. Avoid mixing feature files
4. Every feature should be ready to be executed alone

Scenario:

To describe the scenarios, Gherkin's sentences 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.

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. Background step is run before every scenario.

We have to make sure we don’t put too many steps in there as your scenarios may become hard to understand.

Example is given below

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 those step definitions that we are using frequently in various scenarios e.g “Given: user navigate to the Website” this can be one common step that we need in every scenario. So we can reuse this step.

Reusing the steps improves the maintainability if just in case there’s any change come we need to update in a single step.

We have to make sure language/words should be consistent if we want to re-use the step.

In the below example step is the same the but word isn’t consistent Click and clicks both are different words. So we have to take care of case sensitive to re-use the step.

5. Use Data table

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

Data table is used to inject data at the step level. In the below code we have provided data for step “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 the User clicks on the sign-in button

Then Validate the title after login

6. Use Scenario outline

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

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.

e.g We made a group of smoke test cases and sanity tests. We can put a tag over the scenario

@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 if we will provide the requirement number (#Jira story id) after the scenario in the feature file. If any scenario fails then we can track which requirement is fail from the execution report (See below test case execution screenshot)

In lines #6, and #14 we have specified the requirement number

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 |

9. Avoid conjunctive steps

During writing the feature best practice is we’ve got to avoid conjunctive steps. When you find a Cucumber step that contains two actions in conjunction with an “and”, we should always have to break it into two steps.it is into two steps. Keeping one action per step makes steps more modular and increases reusability. This is not a general rule though. There are also reasons for conjunctive steps. However, most of the time it is best to avoid them.

10. Write in a declarative way, not Imperative

Scenarios should be written sort of a 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.

Declarative Example:

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

Imperative Example:

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. Other scenarios writing rules

Test scenarios should be written in a way that is easy to understand and clears 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

☕️ Happy testing! ☕️

For more blogs please follow the below link

https://qaautomationlabs.com/blogs/