Creation of automated QA test scripts in Cucumber provides a low barrier of entry for your QA team. What is Cucumber? Cucumber is Behavior-Driven Development tool that uses Gherkin for scenario syntax. Gherkin is a simple, non-technical language designed for easy maintenance and readability. Gherkin can easily integrate with open-source tools like Selenium, Appium for QA Automation.
We can extend Gherkin syntax in Cucumber test scripts even further with parameters. Parametrization provides the ability to run your scenarios using different test data, write less code and reuse it in multiple locations. In this article, we will learn how to use parameters to create robust test scenarios.
Before digging deep into parameterization, let’s learn about a few keywords!
Useful Keywords:
Scenario: Group of steps that contains user actions and validations.
Test Step: Represents a single user action or validation defined in simple language and starts with keywords like Given, When, Then, And and But.
Step Definition: A method linked to each test step in a scenario. One step definition also can be linked to multiple test steps by following parameterization techniques.
Scenario Outline: Keyword used for scenarios that contains parameters with values defined. Use Scenario Outline to enable parameters instead of the keyword Scenario. Parameters are defined as variables inside <>. The variables are defined via the Examples keyword.
Examples: Keyword to define variables for a Scenario Outline. I.E. Login credentials for test accounts.
Parameterization Scenarios:
Scenario 1:
Scenario: Verify user can login to Login Page1
Given I am in LoginPage1
When I enter username and password
Then I verify that user is logged into HomePage
And I verify that “home” tab is displayed
And I verify the page title
Scenario 2:
Scenario: Verify user can login to LoginPage2
Given I am in LoginPage2
When I enter username and password
Then I verify that user is logged into HomePage
And I verify that “user” tab is displayed
And I verify the page title and save the title
Parameterize with Pre-defined Values
Parameters that can allow only strongly typed values are considered as pre-defined values.
Let’s look into Given statements from above example – Scenario 1: “I am in LoginPage1” and Scenario 2: “I am in LoginPage2.” The steps are same except for the LoginPage1 and LoginPage2 values. We’re going to create a single step definition for both steps.
@Given(“^I am in (LoginPage1|LoginPage2)$”)
Public void iAmInLoginPage(String parameter1){
//code here
}
Note: The parametrized step definitions will start with ^ and ends with $
Parameterize with Undefined Values
Parameters with undefined values are variables that can have different input values.
We need to test the above scenarios with different login credentials, which can change often. This can be achieved by updating the test data in the scenario, not the entire script linked to the scenario. The test step “When I enter username and password” is the perfect candidate for our use case. Let’s use the Scenario Outline keyword and pass the parametrized values as Examples. We’ll use <> to pass the username and password to our When clause.
Scenario Outlines:
Scenario 1:
Scenario Outline: Verify user is able to login to LoginPage1
Given I am in LoginPage1
When I enter <username> and <password>
Then I verify that user is logged into HomePage1
And I verify that “home” tab is displayed
And I verify the page title and save the title
Examples:
|username|password|
|user1|password1|
|user2|password2|
Note: The above scenario will be executed with iterations for user1 and user2.
The step definitions should use regular expressions to pass values to the scenario as shown below.
@When(“^I enter (.*) and (.*)$”)
Public void iEnterUserNameAndPassword(String username,String password){
//code here
}
Parameterize with Fixed/Default Values:
Default values are parameters defined in test step of the scenario. We are not making use of parameter names, we are directly passing values from test steps instead.
Let’s investigate the test step Scenario 1: “And I verify that “home” tab is displayed” and Scenario 2: “And I verify that “user” tab is displayed.” Both steps are the same except for the values home and user. Even though they aren’t parameter names, they are values used directly in our test steps. However, we can still create single step definition and link it to both test steps.
@And(“I verify that {String} tab is displayed”)
Public void iVerifyGivenTanIsDisplayed(String tabName){
//code here
}
Parameterize Null Values:
There are times when a particular parameter can or cannot have a value within our scenarios. This is where we would make use of Null Value parameters.
Let’s take last steps “And I verify the page title” and “And I verify the page title and save the title.” We can create a parameter to accept “ and save the title” or null. This can be achieved with the regular expression character ? and ensure the parameter has a leading space.
@Then(“^I verify the page title( and save the title)?$”)
Public void iVerifyPageTitle(String saveTitle){
//codehere
If(saveTitle != null){
//code here
}
}
Test scenario parameters enable reuse for test steps across different scenarios. Your code will be more readable and portable as a result. Parameterization decreases our script efforts by linking step definitions to multiple test steps. Adoption of parameters improves code quality which will allow for less errors, easy updates and better overall code.
You will love the code efficiencies that parameters provide! Why not give them a try.
For more information about Perficient’s Mobile Solutions expertise, subscribe to our blog or contact our Mobile Solutions team today!
Totally love this site! It’s extraordinarily easy to understand with a smooth plan. The substance is first class, offering important data in a reasonable and succinct way. Exploring through it is a breeze. Certainly a go-to asset for anybody looking for solid data!