_edited_edited.png)
Behavior Driven Development is a collaborative approach towards the development of a software that encourages communication between technical and non-technical team members throughout the development life-cycle.
Cucumber is a popular open-source automation tool for BDD. Cucumber itself is not a programming language but it is a framework that supports multiple programming languages. It is widely used to write BDD scenarios in a human-readable language called Gherkin.
Scenarios in Gherkin are written in simple English that are easy to read and understand the desired behavior of the application under development.
Cucumber (BDD) Framework has the following folder structure:
1. Feature File
2. Step Definition File
3. Test Execution File
Feature: Describes the high-level functionality.
Scenario : Describes specific test cases.
Example of a Cucumber Feature File written in Gherkin format:
Feature: User Login
Scenario: Successful Login
Given User is on the Login page
When the user enters valid username
And the user enters valid password
And the user clicks on Login
Then the user is navigated to the Home page
Scenario: Login Failed with Invalid Username
Given User is on the Login page
When the user enters invalid username
And the users enter valid password
And the user clicks on Login
Then the login fails
Scenario: Login Failed with Invalid Password
Given User is on the Login page
When the user enters valid username
And the users enter invalid password
And the user clicks on Login
Then the login fails
These scenarios can be used as test cases by QA and used as user stories by developers. So, there will be no gap in understanding the requirements between the two teams.
Points to be kept in mind while framing these scenarios :
Given-When-Then must be written in the same sequence because Given is the precondition, When is when an action is executed and Then is the expected outcome.
Each Scenario should be precise and clear.
Too many “And” should be avoided else it will make the scenario lengthy and complex. A minor change in the behaviour of the application will lead to a lot of changes in the steps of the scenario.
The Scenarios should be written in the sequence you want them to be executed.
Scenarios should be independent of each other.
Other ways to describe Scenarios are :
Background: If preconditions are common for multiple scenarios within a feature file then that can be specified in Background, followed by a set of steps that must be executed before all the scenarios in that feature.
Refer to the screenshot given below:
Cucumber supports Data Driven Testing using Scenario Outline :
Scenario Outline is used for parameterization i.e. where data can be given as input within a scenario.
Structure of a Scenario Outline includes:
“Examples” keyword, followed by a table that provides sets of input data and expected outcome. Each row in the table represents a different set of data for that particular scenario.
Placeholder values : Within the Scenario Outline steps, placeholder values enclosed in angle brackets can be used. These placeholders are used for the dynamic fields of the scenario where the input data will be passed from the “Examples” table.Eg. <username> <password>
Scenario Outline syntax:
Scenario Outline: Login with Valid Credentials
Given the user is on the Login page
When the user enters valid <username> and <email>
Then the user should be successfully logged in
Examples:| username | email || admin| admin@abc.com |
Scenario Outline is also used to eliminate the need of creating a scenario for multiple data set within a feature file. Scenario Outline can be executed mutiple times based on the parameters passed.
Refer to the screenshot below:
Step Definition File : Step Definitions are written in a programming language eg. Java, Ruby, Python etc. and are used to map the Gherkin steps in the feature file to the actual code. Step Definitions define the actions that need to be taken for each step in a scenario, making the scenarios executable. For every Gherkin line there should be a Step Definition in another class.
This is how the Step Definition file will look like based on the following feature file:
package stepDefinition;
public class steps {
@Given(“User launch Chrome Browser”)
public void user_launch_chrome_browser() {
//Code is written here for the execution of the above action
}
@Given(“User opens URL {string}”)
public void user_opens_url(String URL) {
//Code is written here for the execution of the above action
}
@When(“User click on Get Started”)
public void user_click_on_get_started() {
//Code is written here for the execution of the above action
}
@Then(“User should be redirected to homepage”)public void user_should_be_redirected_to_homepage() {
//Code is written here for the execution of the above action
}
@When(“User clicks on Get Started button of Array Data Structure”)
public void user_clicks_on_get_started_button_of_array_data_structure() {
//Code is written here for the execution of the above action
}
@Then(“User is navigated to the Array page”)
public void user_is_navigated_to_the_array_page() {
//Code is written here for the execution of the above action
}
@Then(“The page title is {string}”)
public void the_page_title_is(String title) {
//Code is written here for the execution of the above action
}
Hooks : Hooks are blocks of code that run before or after each scenario in the Cucumber execution cycle. They are defined using the methods @Before and @After.
Hooks are helpful for tasks like launching a browser or closing it, capturing screenshots on test failures etc.
Test Execution File : This file is responsible for running the tests. It is a trigger for the execution of the feature files. It parses the feature files, maps the steps in the Scenarios in the feature file with the corresponding Step Definitions which in turn is mapped with the actual code, and executes all the Scenarios. This is the Test Runner class.
This Runner class will also have all the plugins to generate reports.
This is how the Runner file will look like :
Conclusion :
Hope you find this blog helpful in learning BDD with Cucumber. Behavior Driven Development along with Cucumber is a very impressive approach towards software development, ensuring a clear and no conflict understanding of the behavior of the application by QA, Developers and Business Analysts.
Thank You!