_edited_edited.png)
Welcome to the world of automated testing with Cucumber BDD!In today’s fast-paced digital world, making sure your web applications work well on all browsers is super important. But testing them one by one takes a lot of time and can be a bit tricky. That’s where automated cross-browser testing and parallel testing come to the rescue.
In this guide, we’ll explore how to streamline your testing process and save time using Cucumber BDD for both cross-browser testing and parallel testing. Whether you’re an experienced tester or just starting out in software development, mastering these techniques will enhance the quality and efficiency of your testing efforts.
Let’s dive into the world of cross-browser testing and parallel testing with Cucumber BDD.
Let’s start with my Framework Folder Structure,
MySampleProject Framework
Running the Framework with TestNG:The framework discussed in this guide is designed to be executed using TestNG, a popular testing framework for Java. TestNG offers powerful features for organizing and executing tests, including parallel execution capabilities that are crucial for efficient cross-browser testing.
To run the framework with TestNG, simply configure your test suites and tests using TestNG annotations and XML configurations, as demonstrated in the examples provided.
By leveraging TestNG alongside Cucumber BDD, you can achieve comprehensive and efficient automated testing for your web applications across different browsers, ensuring high quality and reliability with every release.
POM.xml:
The provided pom.xml file is the Project Object Model (POM) configuration for a Maven project. It defines the project's metadata, dependencies, and build settings. Here's a breakdown of the key elements in this pom.xml:
Project Metadata:
groupId: Identifies the group or organization that the project belongs to.
artifactId: Specifies the unique identifier for the project (often the name of the project).
version: Indicates the version of the project.
Dependencies:
Dependencies specify external libraries and frameworks required for the project.
Notable dependencies include:
Selenium WebDriver (selenium-java): For browser automation.
Cucumber Java (cucumber-java) and TestNG (cucumber-testng): For implementing BDD-style tests and executing them with TestNG.
TestNG (testng): Testing framework for Java.
WebDriverManager (webdrivermanager): Simplifies management of WebDriver binaries.
SLF4J (slf4j-api and slf4j-simple): Logging framework.
Build Configuration:
<build> section contains configuration settings for the Maven build process.
<plugins> section specifies Maven plugins to be used during the build.
maven-surefire-plugin: Responsible for running tests with TestNG.
<suiteXmlFiles>: Specifies the TestNG XML configuration file to be used (testng.xml).
<properties>: Configures properties for the test execution.
dataproviderthreadcount: Specifies the number of threads to use for data providers.
parallel: Specifies the parallel execution mode (e.g., tests).
threadCount: Specifies the total number of threads to use.
<systemPropertyVariables>: Allows passing system properties to the test execution environment (e.g., browser type).
dependencies used in this framework
plugins used in this framework
This pom.xml file sets up the Maven project to use Selenium WebDriver with TestNG and Cucumber for BDD-style testing, enabling parallel execution of tests with TestNG and specifying browser configuration through system properties.
You can customize the dependencies, build configuration, and properties according to your project requirements.
2. testng.xml:
This XML file defines the TestNG test suite for cross-browser testing.
It includes configurations for parallel execution with a specified thread count.But this parallel execution happen on cucumber feature file level not on scenario level.
To achieve Scenario wise parallel execution — We can use one of the methods provided by AbstractTestNGCucumberTests is the scenarios()method, which is responsible for providing the scenarios (test cases) to be executed by TestNG. By default, this method returns an array of arrays containing all the scenarios defined in your feature files.We will see detailed explanation on this in TestRunner.
Two test cases, “ChromeTest” and “EdgeTest,” are defined with parameters specifying the browser type. You can add your preferred browsers.
3. TestRunner1.java:
This Java class serves as the Test Runner for Cucumber BDD.
It sets up Cucumber options for feature files, reporting, and glue code.
The defineBrowser method sets the browser type based on the parameter provided in the testNG.xml file.
It overrides the scenarios method to enable parallel execution.
Let’s break down the method defineBrowser(String browser) and its purpose below,
Method Signature:
@BeforeTest: Annotation indicating that this method should be executed before any test method.
@Parameters({"Browser"}): Indicates that this method expects a parameter named "Browser" from the TestNG XML configuration file (note: refer testng.xml).
public void defineBrowser(String browser) throws Throwable: The method signature specifies that defineBrowser takes a single parameter of type String named browser. It also specifies that the method may throw a Throwable.
Method Functionality:
When TestNG runs, it looks for methods annotated with @BeforeTest and executes them before any test method in the test class.
The @Parameters annotation indicates that TestNG should inject values for the specified parameter from the test suite XML file.
In this case, the method expects a parameter named “Browser” from the test suite XML file.
Inside the method, the value of the “Browser” parameter is received as an argument (String browser).
ConfigReader.setBrowserType(browser): This line sets the value of the browser type in your configuration reader utility class (note: refer ConfigReader) using the value provided as the parameter.
Purpose:
The purpose of this method is to set the browser type for the test execution dynamically based on the value provided in the test suite XML file.
By using parameters, you can configure and execute the same test class with different browser configurations without modifying the test code. This allows for greater flexibility and reusability in your test automation framework.
For example, if you have multiple browser configurations (e.g., Chrome, Firefox, Edge) defined in your test suite XML file, TestNG will invoke this method with the specified browser value before executing each test method, ensuring that tests are run on the desired browser.
Overall, the defineBrowser() method ensures that the appropriate browser configuration is set up before executing any test method, enabling flexible and dynamic browser testing in your automation framework.
Let’s break down the code for Scenario level parallel Testing and its purpose below,
Annotation and Method Signature:
@Override : This annotation is used to indicate that the following method is overriding a method from a superclass or interface.
@DataProvider(parallel = true): This annotation is used to indicate that the method serves as a data provider for test methods, and the data provided by this method can be used in parallel test execution.
public Object[][] scenarios(): This method returns a two-dimensional array of Object's. It's annotated with @DataProvider to indicate that it's a data provider method for TestNG tests.
Purpose:
The purpose of a data provider method in TestNG is to supply test data to test methods during test execution.
By specifying parallel = true, you're indicating that the data provided by this method can be used in parallel test execution. This means that TestNG can invoke test methods in parallel using the data supplied by this data provider.
Functionality:
Inside the scenarios() method, super.scenarios() is called. This typically invokes the superclass's scenarios() method (since scenarios() is overridden), which is likely a method provided by AbstractTestNGCucumberTests or another superclass.
The superclass’s scenarios() method is responsible for fetching and providing the scenarios (test cases) defined in your Cucumber feature files. These scenarios are usually defined as sets of steps in Gherkin syntax.
By returning the result of super.scenarios(), essentially using the scenarios provided by the superclass as the test data in TestNG tests.
Parallel Execution:
Since @DataProvider(parallel = true) is specified, TestNG will leverage parallel execution capabilities when using the data provided by this data provider.
TestNG will execute test methods in parallel, each using different sets of data obtained from the scenarios() method. This can help speed up test execution by utilizing multiple threads to run tests concurrently.
Overall, the scenarios() method serves as a data provider for TestNG tests, supplying test scenarios obtained from feature files. By annotating it with @DataProvider(parallel = true), this enable parallel execution of tests using the data provided by this method, enhancing the efficiency of test automation.
Note: In default , it will run 10 Scenarios in parallel. If you want more scenarios according to your need you can add count in pom.xml like below,
Here i have increased to 30
4.Feature File:
The feature file contains scenarios tagged with @Graph, indicating that they are related to graph functionality.
Each scenario outlines a particular flow within the application, starting from the home page after logging in and proceeding through various interactions with the graph-related features.
I am have 1 feature file with 3 Scenarios here.
Scenarios are divided into steps using Given, When, and Then keywords to describe the preconditions, actions, and expected outcomes.
Sample FeatureFile
5. Step Definitions:
The step definitions in “DSGraphStepDefinition.java” correspond to the steps defined in the feature file.
Each step definition method implements the behavior described in the corresponding step of the feature file.
Methods interact with the page elements using Page Object Model (POM) and Selenium WebDriver methods to perform actions such as clicking buttons, entering text, and verifying page navigation and content.
Assertions are used to validate expected outcomes and ensure the application behaves as intended during testing.
6. Page Object Model (POM):
The “GraphPage.java” class represents the Page Object Model (POM) for the graph-related pages.
It contains WebElement declarations for various elements on the pages, such as buttons, links, and text fields.
Methods in the class encapsulate interactions with these elements, providing a clean and modular approach to test automation.
Overall, the feature file, step definitions, and Page Object Model work together to automate testing of the given functionality of the web application, ensuring it behaves as expected under different scenarios.
This class manages the configuration settings for the test environment.
It loads properties from a config.properties file, including URL, username, and password.
The setBrowserType method sets the browser type based on the parameter provided in the testNG.xml file.
Generate getter and setter for browsertype=null;
generating Getter and Setter
After generated the getter and setter for given initailized variable
The setBrowserType method sets the browser type based on the parameter provided in the testNG.xml file
It loads properties from a config.properties file, including URL, username, and password
sample config.properties
This class manages the WebDriver instances for different browsers.
It includes methods to launch the browser based on the specified browser type.
The getDriver method provides access to the WebDriver instance.
9. Hooks.java:
This class contains Cucumber hooks for setup and teardown actions before and after scenarios.
The beforeScenario method initializes the WebDriver, loads properties, sets up browser configuration, and launches the URL.
The driverClose method closes the WebDriver after scenario execution.
Overall, these components (1,2,3,7,8,9) work together to facilitate automated cross-browser testing and parallel testing using Cucumber BDD with TestNG.
10.Running Tests with TestNG:
To execute your test automation framework as a TestNG suite, follow these steps:
Run TestNG Suite from IDE:
Navigate to the project containing your TestNG suite configuration file (testng.xml).
Locate the testng.xml file in the project explorer or file system.
Right-click on the testng.xml file to open the context menu.
Select “Run As Test Suite”:
Look for an option similar to “Run As” or “Run Configurations”.
Click on “Run As Test Suite” to execute TestNG suite configuration.
Observe Test Execution:
Once you initiate the test suite execution, the IDE will start executing the tests according to the configurations specified in the testng.xml file.
You can monitor the progress of test execution in the IDE’s console .
IDE console you can see its opening chrome browser for each scenario at the same time to execute in parallel
3 chrome browsers for 3 scenarios
You can see 3 Scenarios are running in Parallel in Chrome Browser
IDE console you can see its opening edge browser for each scenario at the same time to execute in parallel
3 Edge browsers for 3 scenarios
You can see 3 Scenarios are running in Parallel in Edge Browser
11.Test Results:
Attaching the complete TestResult here,
Overall HTML Report
Conclusion:
In this blog post, we’ve explored the details of cross-browser testing and parallel testing using Cucumber BDD, along with practical implementation examples. By utilizing the power of automated testing, we can ensure the quality and reliability of our web applications across different browsers and environments.
We’ve covered essential concepts such as configuring test suites, running tests in parallel, and analyzing test results. Additionally, we’ve demonstrated how to leverage TestNG and Maven to streamline the testing process and maximize efficiency.
I hope this guide has provided valuable insights into optimizing your testing workflow.
Stay tuned for my next blog post, where we’ll explore into running tests using Maven and further enhance our test automation capabilities.
Thank you for joining me on this journey towards mastering test automation with Cucumber BDD and TestNG. If you have any questions or feedback, feel free to leave a comment below. Until next time, happy testing!