A Comprehensive Guide to Implementing BDD testing in Katalon Studio

This article will explore how we can perform BDD testing in Katalon Studio. We will dive into creating a BDD Feature file and Step Definition file in Katalon Studio for a test case and perform execution of the test by two methods: Directly running the Feature file and utilizing in-built Keywords to run it from the Test Case. As we delve deeper, we’ll look into the concept of parameterization in BDD testing by using it in our test case.

BDD, or Behavior-Driven Development, is a software development and testing approach that aims to improve collaboration between developers, testers, and stakeholders.

BDD focuses on the system’s behavior or expected outcomes rather than the technical details. It encourages clear communication and a shared understanding of the software’s behavior among all team members. In the context of testing, BDD provides a framework for writing test cases in a more natural language format that is easily understandable by non-technical stakeholders as well. These test cases are known as “BDD scenarios” or “BDD test cases.”

Key elements of BDD in testing include:

Gherkin Language: We write BDD scenarios typically using a specific syntax called Gherkin. Gherkin uses a structured, easy-to-read format with Given, When, and Then steps to describe the behavior of the system in a human-readable language.
Given-When-Then (GWT): The Gherkin language follows the Given-When-Then (GWT) format:

Given: Describes the initial state or context of the system.
When: Describes the action or event that occurs.
Then: Describe the expected outcome or result.

User Stories: BDD scenarios are often based on user stories or requirements expressed in a non-technical manner, which helps align the testing efforts with business goals.
Test Automation: BDD scenarios can be automated to execute the tests against the application. Automation frameworks like Cucumber, SpecFlow, and JBehave are commonly used for implementing BDD in test automation.

Feature File

A Feature file defines the high-level description of a feature or functionality of the software application being tested; it is a plain text file written in the Gherkin language, which is a structured, human-readable language used to describe the behavior of the software system in a BDD style. Feature files typically have a “.feature” extension.

Step Definitions

The Step Definition file, sometimes referred to as “Step Definitions” or “Step Implementations,” is a code file associated with the Feature file. It contains the actual automation code that maps the steps defined in the Feature file to the corresponding test actions in the automation framework. When the automated BDD tests are executed, the automation framework reads the Step Definition file and executes the corresponding code for each step in the Feature file.

Creating a Feature File in Katalon Studio

We will create a Login test for a website and implement BDD using Cucumber.

Go to Katalon Test Explorer > Include > features > Right click on it > New > Feature file > name it as “Login.feature”
Below is the Gherkin Snippet of our test case:
Feature: Test Login Functionality
Scenario Outline: Check login is successful with valid credentials
Given user is on login page
When user enters username and password
And clicks on login button
Then user is navigated to the home page

Go to Katalon Test Explorer > Include > scripts > groovy > package > Right click on it > New > Step Definition > name it as “LoginSteps”

We will then map the steps of the feature file inside the Step Definition (SD) class and create a method for each Given When, And, and Then step. Finally, we will do test step scripting inside the methods. Alternatively, we can record the test case from the “Test Cases” section in Test Explorer and then copy the script from the “</>Script” tab of the test case into the methods of SD file. Finally, add respective Tags to map the method to the feature file step: @Given, @When, and @Then. Below is the code snippet of Step Definition:

public class LoginSteps {

@Given (“user is on login page”)
public void user_is_on_login_page_enters_username_and_password() {

WebUI.openBrowser(”)
WebUI.navigateToUrl(“https://opensource-demo.orangehrmlive.com/web/index.php/auth/login”)
}
@When (“user enters (.*) and (.*)”)
public void user_enters_username_and_password(String username, String password) {

WebUI.setText(findTestObject(‘Object Repository/Page_OrangeHRM/input_Username_username’), username)
WebUI.setText(findTestObject(‘Object Repository/Page_OrangeHRM/input_Password_password’), password)
}

@When(“clicks on login button”)
public void clicks_on_login_button() {

WebUI.click(findTestObject(‘Object Repository/Page_OrangeHRM/button_Login’))
}

@Then(“user is navigated to the home page”)
public void user_is_navigated_to_the_home_page() {

WebUI.verifyTextPresent(‘Dashboard’, false)

WebUI.closeBrowser()
}
}

Executing the Feature File Test

Running Feature File:

Select the feature file and click on the “Run” icon.

The system runs the feature file, reads the test from the Step Definition file, and executes the corresponding code for each step in the Feature file.

We can check the Logs and Console for the details of execution.

Running Feature file from Test Case:

Create a new test case in the “Test Cases” section in Test Explorer as “Login Test.”
Open the “Keyword Browser” > Built-in Keywords > Cucumber Keywords > General > Drag and Drop the “Run Feature File” keyword in our test case.
In the input column for the step, we must give our feature file ID (path).
Right-click on the feature file and copy ID > paste it in “Input” > “Value” > save and run the test case.
The feature file will execute.

Parameterization in BDD

Parameterization in BDD testing refers to the process of passing dynamic values or data into BDD scenarios or step definitions. It allows you to run the same scenario with different input values, making your tests more versatile and efficient.

Parameterization is essential for testing various scenarios and edge cases without duplicating the entire scenario. It helps ensure that your BDD tests cover different test cases effectively without writing separate scenarios for each specific test case.

In BDD testing, placeholders called “Scenario Outline” or “Examples” in Gherkin, the language used to write Feature files, typically achieve parameterization. These placeholders act as variables and substitute real values while executing tests.

We will take the same test and parameterize username and password values to give different values as input.

Replace the static username and password with placeholders <username> and <password>.
Create an Examples section and provide different values for the placeholders in the format as shown in the image below:
For this parameterize step, we must edit the respective method in Step Definition to accept values as arguments

Below is a code snippet of the method:

@When (“user enters (.*) and (.*)”)
public void user_enters_username_and_password(String username, String password) {

WebUI.setText(findTestObject(‘Object Repository/Page_OrangeHRM/input_Username_username’), username)
WebUI.setText(findTestObject(‘Object Repository/Page_OrangeHRM/input_Password_password’), password)
}

Note: In Tag, we have used the Regular expression “(.*)” instead of static value to accept dynamic value. We have different types of expression, which we can find in various documentation available online.

Save and run the file using any of the above methods.
The feature file will run as many times as inputs are available in the feature file.

Conclusion

In this blog, we have explored the concept of BDD and its components: Feature file and Step Definition. We created the Feature file and step Definition for a sample Login test. Finally, we went through Parameterization in BDD and added it to our test case.