iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To run TestNG tests in parallel through Maven, configure Maven Surefire to execute your TestNG suite, then set a parallel mode and thread limit in the suite XML. For dynamic control, do not assume that a Maven -D property automatically changes TestNG’s thread-count: the property must be connected to the suite configuration or generated suite file for your specific Maven and Surefire setup.
What “full parallel execution” means in TestNG
TestNG does not have one switch that makes every level of a build parallel. Choose the unit of work to run concurrently: methods, TestNG <test> groups, classes, or separate suite files. These boundaries are distinct, and parallel scheduling does not make tests that share mutable state safe.
| Setting or option | What it runs concurrently | Limit or scope |
|---|---|---|
parallel="methods" |
Test methods | Suite thread-count sets the regular test pool limit. |
parallel="tests" |
TestNG <test> groups |
Suite thread-count sets the regular test pool limit. |
parallel="classes" |
Classes | Suite thread-count sets the regular test pool limit. |
-suitethreadpoolsize |
Separate suite XML files | Controls concurrent suites, not the methods or classes inside one suite. |
TestNG documents the three suite-level parallel modes and the separate suite thread-pool option in its parallel execution documentation. If methods in a class must stay on one thread even with method parallelism, TestNG provides singleThreaded for that class.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Configure Maven and the TestNG suite
Maven needs TestNG on the test classpath and a test runner configuration suitable for the project’s Maven, Java, and plugin versions. TestNG’s Maven guide demonstrates a test-scoped dependency and points to Maven Surefire for execution. Its dependency examples vary by JDK generation, so choose versions compatible with your project rather than treating an example as a universal current version.
#1 Best Overall
In the suite XML, choose a parallel mode and provide a thread limit. This example uses TestNG 7.9.0 or later because it includes shared-pool attributes; the values are illustrative, not a performance recommendation.
<!DOCTYPE suite SYSTEM "https://testng.org/testng-1.1.dtd">
<suite name="Parallel suite"
parallel="methods"
thread-count="5"
data-provider-thread-count="5"
use-global-thread-pool="true">
<test name="Application tests">
<classes>
<class name="example.ApplicationTest"/>
</classes>
</test>
</suite>Run the project’s configured Maven test goal, commonly mvn test. The exact Surefire setup depends on the plugin and project versions; consult the project’s existing configuration and TestNG’s Maven integration guidance rather than assuming one plugin configuration fits every build.
Understand what the thread limits control
TestNG’s thread-count sets the regular parallel test limit only when a parallel mode is selected. A configured number on its own does not enable parallel execution. The command-line option -threadcount supplies a default maximum for parallel tests; the suite XML can set or override the value.
Data providers have a distinct default limit: -dataproviderthreadcount controls parallel data-provider execution, and it too applies only when parallel mode is selected. Suite XML can set data-provider-thread-count. Consider the distinction when a suite combines ordinary test methods with tests that run through data providers: two independently configured limits can allow more concurrent work overall than either number alone suggests.
Choose whether test work shares a pool
TestNG 7.9.0 added suite-level ways to control thread-pool sharing. These attributes use the testng-1.1.dtd suite declaration and default to false. Choose one based on which work should compete for the same execution capacity.
| Suite attribute | Pool behavior | Pool size |
|---|---|---|
use-global-thread-pool="true" |
Regular and data-driven tests share one suite-level pool. | thread-count |
share-thread-pool-for-data-providers="true" |
Data-provider tests share a pool with one another, separate from regular tests. | data-provider-thread-count |
These are pool-sharing controls, not alternate names for dynamically changing the numeric thread limit. Select a concurrency value that fits the test environment, shared fixtures, and external services; TestNG cannot determine whether those resources can safely sustain a chosen load.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Change the thread count between Maven runs
There are three practical configuration paths, with different levels of certainty:
Recommended Free Tools
- Keep a fixed limit: set
thread-countand, when relevant,data-provider-thread-countintestng.xml. This is the most direct option when the suite should use the same limit on every run. - Choose a value per Maven execution: pass a system property or have the build generate or configure the suite XML for that run. TestNG documents runtime JVM system properties and says they can override XML parameters; Surefire can pass JVM arguments and system properties to the test process. However, those facts do not establish a universal property name that Surefire automatically binds to the suite’s
thread-count. Verify the property interpolation or suite-generation mechanism in your project’s Surefire configuration before relying on it. - Change how work shares capacity: use the 7.9.0-and-later pool-sharing attributes when the need is to combine regular and data-provider work, or to share capacity among data providers. These attributes do not by themselves provide a per-run numeric override.
TestNG’s parameters documentation covers runtime properties and XML parameters. The Maven binding between a property and suite thread count depends on the project’s actual runner and configuration, so test the selected approach rather than assuming that a command such as mvn test -DthreadCount=8 changes the suite limit automatically.
Quick Recap
Best Value
Validate parallel behavior and troubleshoot it
- Tests still run sequentially: confirm that the active suite XML is the one Surefire executes and that it declares a parallel mode. A thread count without a selected mode is not sufficient.
- Data-provider work does not use the expected limit: check
data-provider-thread-count, the selected parallel mode, and whether a shared-pool setting changes which pool governs the work. - A Maven property has no effect: verify that Surefire passes the property to the test process and that the suite configuration explicitly consumes it or is generated using it. Passing a system property alone does not prove it is mapped to
thread-count. - Failures appear only under parallel load: investigate shared mutable state, setup or teardown assumptions, and contention for external services. If methods from a class must stay on one thread, consider TestNG’s
singleThreadedbehavior for that class or choose a broader parallel boundary such as classes or test groups. - Multiple suite files run concurrently: distinguish suite-level concurrency configured with
-suitethreadpoolsizefrom concurrency inside each suite. Both can contribute to the total work reaching constrained resources.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
