How to Use Runner Class in Cucumber
Regular manual testing of the same test cases can waste time and money. It can also be boring for testers. We use test automation frameworks to make the same test scenarios run at regular intervals more efficient and save time and money. These frameworks develop over time and provide us with many conveniences. Today I will explain Runner Classes, an important feature of the Cucumber framework used with Selenium. First, I will briefly explain the runner classes and then I will write a sample automation code to show how it can be used in a real project. .
1. What is the Cucumber Framework ?
Cucumber is a BDD (Behavior Driven Development) tool that supports behavioral software development. BDD uses more understandable expressions to understand the software’s behavior and user scenarios. In this way, employees and business partners other than testers can clearly understand the purpose, scenarios and stages of the written automation.
The most important element that increases the understandability of automation written in Cucumber is the writing of test scenarios in Gherkin expressions. Scenarios are written in “feature” files in Gherkin format.
You can run your project from “feature” file. But this situation is not healthy in many ways. It would be better to use “Runner” classes to specify run conditions and apply filters to our test.
2. Using The Runner Class in a Real Project
Runner classes are classes that allow us to develop our project, choose which scenarios to run, and create test reports.
These parameters should be written inside the @CucumberOptions notation.
I created a simple automation project on hepsiburada.com. I will not explain classes other than the Runner class because they are out of scope in this article. But I will add the github link of my project to end of the article. You can see the other classes and structure of the project.
Runner class of the project:
2.1 Plugin
A path is given to this parameter. In this way, the test report of the run test is created and saved to the path we specified with the name we specified. Thanks to this parameter, we do not need to make an extra setup to report our test result.
plugin = "html:target/reports.html"
As seen in the screenshot above, a report file was created in target file after the test is over. Report path can be changed from runner class.
2.2 Features
We write the paths of the features we want to run in our project here.
features = "src/test/resources/features"
2.3 Glue
Thanks to this parameter, we specify which class the codes of the test scenario we will run are under.
glue = "stepdefinitions"
Since the codes of the test scenario we will run are in the stepdefinitions file, we wrote stepdefinitions to this parameter.
2.4 dryRun
As you know, in cucumber we first write the test steps and then write the codes of these steps. With the dryRun parameter, we determine whether test steps whose codes have not been written yet will be run. It can take 2 values. Default value of the parameter is “false”. When the value of the parameter is “false”, all scenarios are run, including the steps whose codes are not written. While the value of the parameter is “true”, if there are test steps for which code methods have not been created, the test will not be started. An error message will be returned indicating that there are test steps whose methods have not been written yet and how these methods should be written.
Let’s examine these two conditions.
Created a new feature file. As you see, methods of some steps are missing.
dryRun = false
When the project was run with the dryRun parameter set to false, the last scenario we added was skipped and other scenarios were run. An error message was returned stating that these scenarios do not have code methods and how these methods can be created.
dryRun = true
When the dryRun parameter was set to true, no scenario was run because there were missing code methods in one of the scenarios and an error was returned directly. You can understand from the running times that the other scenarios are not run.
2.5 Tags
We may not always want to run all test cases. This is the parameter where we specify which test cases we will run. For example: If we write @smoke on one or more scenarios and write @smoke in front of the “tags” parameter, only scenarios with the @smoke tag will be run.
Let’s add some tags to our scenarios.
Now, let’s examine some cases where the tags parameter does not have a value and where it does.
tags = ""
tags = "@login"
tags = "@regression"
tags = "@regression and not @login"
3. Summary
In a test automation project using the Cucumber framework, tests can be run without using the Runner class, but using the Runner class gives us great advantages. We can easily report using the Runner class and specify where we want the report to be saved and only run the tests we want to run. Especially if you have a large automation project, using the Runner class is a must.
That’s All
Thank you for reading my article. I hope it will help you. If you have a question or advice, you can contact me via my e-mail address below.
İbrahim Alper Yiğit, QA Test Engineer
ialper.yigit@gmail.com
