Parallel Testing in Cucumber BDD Framework with TestNG

Parallel Testing is a powerful technique that allows multiple test cases to run simultaneously, significantly reducing execution time and enhancing efficiency-especially in large test suites.

In Cucumber BDD(Behaviour Driven Development) parallel testing helps in executing multiple Cucumber scenarios or feature files at the same time.

Benefits of Parallel Testing:

Parallel testing offers several advantages that make it a crucial component of test automation and CI/CD pipelines. Here are its key benefits:

• Speed and Efficiency

• Better Resource Utilization

• Expanded Test Coverage

• Supports Scalable Automation

Cucumber itself doesn’t natively support parallel execution, but it integrates with frameworks like TestNG, JUnit, and Cucumber JVM to enable it. These frameworks allow multiple feature files or scenarios to execute simultaneously.

Setting Up Parallel Testing in Cucumber:

Step 1: Adding dependencies in pom.xml

Here, we are using TestNG to implement parallel execution in cucumber . So add the necessary dependencies in the pom.xml file

<dependency>
			<groupId>io.cucumber</groupId>
			<artifactId>cucumber-testng</artifactId>
			<version>7.21.1</version>
		</dependency>
		
		<dependency>
			<groupId>org.testng</groupId>
			<artifactId>testng</artifactId>
			<version>7.10.2</version>
			<scope>test</scope>
		</dependency>

• cucumber-testng: Integrates Cucumber with TestNG so you can run Cucumber scenarios using the TestNG runner.

• testng: The actual testing framework required to execute tests and define test configurations.

Step 2: Creating TestNG.xml file

The TestNG.xml file is a configuration file for TestNG, used to define and manage test execution.

Parallel execution in TestNG allows multiple tests to run simultaneously, improving efficiency, especially in large test suites. The testng.xml file plays a crucial role in configuring parallel execution.

Here's an example of a TestNG XML file for running tests in parallel:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd">
<suite name="ParallelSuite" parallel="methods" thread-count="3">
    <test name="Chrome Test">
        <parameter name="browser" value="Chrome" />
        <classes>
            <class name="dsAlgo_Runner.TestRunner" />
        </classes>
    </test>
</suite>

Key Elements of TestNG.xml file:

• <suite> Tag:

  • parallel="methods" → Enables parallel execution at the method level.

  • thread-count="3" → Sets the number of threads TestNG will use.

• <test> Tag:

  • Groups related test cases that should run together.

  • Can include parameters, like browser in this example.

• <classes> Tag:

  • Lists the test classes that will execute in parallel.

Step 3: setting up runner file

We have to enable parallel execution for cucumber test using TestNG in runner file.

public class TestRunner extends AbstractTestNGCucumberTests{	
			
	@Override
    @DataProvider(parallel = true)
    public Object[][] scenarios() {
				
		return super.scenarios();
    }	
}

Parallel Execution Enabled:  

• The method scenarios(), is a key component of enabling parallel execution in Cucumber using TestNG.

• The @DataProvider(parallel = true) annotation ensures that Cucumber scenarios will run in parallel rather than sequentially. This is crucial for improving test execution speed.

• The method public Object[][] scenarios(),overrides the scenarios() method from AbstractTestNGCucumberTests. It provides Cucumber scenarios to TestNG in a structured format, allowing each scenario to be treated as a separate test case.

• The method super.scenarios(), calls the scenarios() method from AbstractTestNGCucumberTests, which internally retrieves all test scenarios from feature files. And ensures that the test cases defined in your feature files are executed in the framework.

Step 4: Web Driver Management

WebDriver instances are managed using the Driver Factory class. Below is an example of a Driver Factory class

public class DriverFactory {

private static ThreadLocal<WebDriver> threadDriver = new ThreadLocal<>();
static ConfigReader configReader;
private static final Logger logger= LoggerFactory.getLogger(DriverFactory.class);
public final static int TIMEOUT = 2;
static String browserType = null;

public WebDriver driverSetup(String browser) {
		if (browser.equalsIgnoreCase("Chrome")) {
			threadDriver.set(new ChromeDriver());
		} else if (browser.equalsIgnoreCase("Firefox")) {
			threadDriver.set(new FirefoxDriver());
		} else if (browser.equalsIgnoreCase("Edge")) {
			threadDriver.set(new EdgeDriver());
		} else {
			threadDriver.set(new ChromeDriver());
		}
		WebDriver driver = threadDriver.get();
		     	 	driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(TIMEOUT));
driver.manage().window().maximize();
logger.info("Driver initialised with browser as:  "  +browser) ;
return driver;
	}

• How It Works in Parallel Execution:

  • When a test starts, each thread initializes its own WebDriver instance.

  • Thread-Safe WebDriver Instance (ThreadLocal<WebDriver>) ensures each test thread gets its own separate WebDriver instance, avoiding conflicts when running tests in parallel.

  • Each thread can retrieve its respective WebDriver using threadDriver.get().

  • After execution, the WebDriver should be properly closed and removed .

  
  

Why we choose TestNG for parallel execution?

• TestNG natively supports parallel test execution via its testng.xml configuration file, allowing you to define parallel execution at different levels, such as methods, classes, test, suites.

• Unlike JUnit, TestNG provides better control over thread pools, letting you optimize execution speed and resource utilization.

• Cucumber is fully compatible with TestNG can define multiple runner classes and execute them in parallel.

What challenges Parallel Testing solve?

Parallel testing in Cucumber BDD solves several critical challenges in test automation, making execution faster and more efficient. Here are some key problems it addresses:

1. Slow Test Execution

• Running tests sequentially can be time-consuming, especially with large test suites.

• Parallel execution reduces total test runtime by running multiple scenarios simultaneously.

2. Bottlenecks in CI/CD Pipelines

• Continuous Integration (CI) pipelines often require fast feedback from test automation.

• Parallel testing speeds up validation, allowing quicker deployments and reducing delays.

3. Resource Underutilization

• In sequential execution, CPU cores and test environments are often idle.

• Parallel execution maximizes resource usage, ensuring multiple tests are running concurrently.

4. Flaky Tests Due to Environment Conflicts

• Test cases may fail intermittently due to shared test environments.

• Parallel execution isolates tests, reducing environmental interference.

Thanks for reading the blog!

Hope you found it helpful — happy learning!