DEV Community

Shell QA
Shell QA

Posted on

How to Configure Full Parallel Execution in TestNG via Maven (with Dynamic Thread Control)

#testing #automation #java #devops

Running automation test suites sequentially can quickly become a bottleneck in CI/CD pipelines. To optimize execution efficiency, you can enable full parallel execution using TestNG and Maven, allowing you to control thread counts dynamically right from the command line without modifying XML files every time.

Here is a step-by-step guide on how to configure your framework for flexible parallel execution, along with a comparison of native TestNG execution versus custom Allocator/Run Manager approaches.

Step-by-Step Configuration

1. Update testng_regression.xml

Modify the tag to set your default parallel mode and thread count. You can set parallel to methods, classes, tests, or instances based on your architecture:


<suite name="Regression" parallel="methods" thread-count="10">
Enter fullscreen mode Exit fullscreen mode

2. Configure pom.xml for Dynamic Control

To override these settings at runtime without touching the codebase, map properties inside the block of the maven-surefire-plugin:


<configuration>
    <parallel>${parallel}</parallel>
    <threadCount>${threadCount}</threadCount>
</configuration>
Enter fullscreen mode Exit fullscreen mode

Command-Line Usage Examples

Once configured, you can pass parameters dynamically via Maven:

  • Default Run (10 threads): 
   mvn clean test -P runTestNGTests
Enter fullscreen mode Exit fullscreen mode
  • Dynamic Thread Count (15 threads): 

   mvn clean test -P runTestNGTests -DthreadCount=15
Enter fullscreen mode Exit fullscreen mode
  • Change Parallel Mode at Runtime: 

   mvn clean test -P runTestNGTests -Dparallel=classes -DthreadCount=15
Enter fullscreen mode Exit fullscreen mode
  • High-Throughput Run (Match CPU cores, e.g., 24 threads): 

   mvn clean test -P runTestNGTests -DthreadCount=24
Enter fullscreen mode Exit fullscreen mode

Comparison: Native TestNG vs. Custom Excel Allocator

If your framework currently uses a custom Excel-based Run Manager alongside native TestNG, here is how the two approaches compare:

Feature / Aspect Custom Allocator (Run Manager) Native TestNG
Entry Point allocator.Allocator.main() via Maven exec plugin maven-surefire-plugin running testng.xml
Test Selection Reads Excel sheets via custom properties Reads testng_regression.xml classes/methods
Thread Management Managed via custom ExecutorService Native TestNG thread pool (parallel + thread-count)
Execution Command mvn clean test -P runAllocator mvn clean test -P runTestNGTests
Pros Data-driven via Excel; multi-sheet aggregation support Lightweight, faster startup, zero Excel dependencies
Cons Requires global property tuning; code changes for structural updates Restricted to TestNG parallel modes (methods/classes)

Which Approach Should You Choose?

  • Choose Custom Allocator if your suite relies heavily on fine-grained Excel-driven iteration control or multi-sheet test scheduling.

  • Choose Native TestNG if you want a cleaner footprint, faster execution loops without file-parsing overhead, and straightforward CLI thread scaling.

Top comments (0)