DEV Community

Shell QA
Shell QA

Posted on

How to Configure Parallel Execution in TestNG vs. Custom Excel Allocator

#java #testing #testng #devops

Optimizing test execution speed is essential for keeping build pipelines lean. Depending on how your framework is structured, you can achieve full parallel execution either natively using TestNG ** or dynamically using a **Custom Excel Allocator.

Here is a step-by-step guide on configuring both approaches, along with a comparison to help you choose the right strategy.

Strategy 1: Native TestNG Parallelization (Recommended for Code-Native Suites)

TestNG natively supports parallel execution at the methods, classes, tests, or instances level using its XML configuration or Maven parameters.

1. Update testng_regression.xml
Modify the tag to set the execution mode and thread pool size:

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

2. Configure pom.xml for Dynamic Overrides

Allow developers and CI pipelines to override execution settings without altering XML files by adding these lines inside the block of the maven-surefire-plugin:

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

3. Execution Commands

  • Default Run: 
   mvn clean test -P runTestNGTests
Enter fullscreen mode Exit fullscreen mode
  • Override Thread Count Dynamically: 
   mvn clean test -P runTestNGTests -DthreadCount=15
Enter fullscreen mode Exit fullscreen mode
  • Full Parallel Execution (Match CPU Core Count): 
   mvn clean test -P runTestNGTests -Dparallel=methods -DthreadCount=24
Enter fullscreen mode Exit fullscreen mode

Strategy 2: Custom Allocator & Run Manager (For Excel-Driven Suites)

If your framework relies on an Excel-driven Run Manager to parse keyword flows and data sheets dynamically, parallelism is managed via a custom ExecutorService fixed thread pool.

Execution Command

mvn clean test -P runAllocator
Enter fullscreen mode Exit fullscreen mode
  • How it works: The allocator reads active test rows (Execute=Yes), dynamically assigns thread pools based on target thread properties, and dispatches concurrent runs.

Comparison: Allocator (Run Manager) vs. Native TestNG

Feature Allocator (Run Manager) TestNG Native
Entry Point allocator.Allocator.main() via Maven Exec Plugin maven-surefire-plugin executing testng.xml
Test Selection Reads Excel sheets via central properties Reads testng_regression.xml test classes/methods
Thread Management Java ExecutorService (FixedThreadPool) TestNG internal thread pool (parallel + thread-count)
Command mvn clean test -P runAllocator mvn clean test -P runTestNGTests
Pros Pure data-driven control; multi-sheet aggregation; exact instance control Lighter weight; no Excel dependency; native TestNG integration
Cons Requires property tuning; multi-sheet parsing requires custom code Limited to test methods/classes; lacks Excel data loop control

Which Approach Should You Choose?

  • Choose Native TestNG if you want:

    • Simple, code-first test execution.
    • Faster execution loops without file parsing overhead.
    • Standardized parallel="methods" or parallel="classes" handling.

  • Choose Allocator + Run Manager if you want:

    • Multi-sheet Excel data-driven scheduling.
    • Fine-grained control over test iteration instances based on data rows.
    • Integration with existing property-driven suite configs.

Top comments (0)