What is the use of @Test(invocationCount=x)?

In TestNG, @Test(invocationCount=x) tells the framework to run the same test method x number of times. The value of x sets how many repetitions occur, so @Test(invocationCount=5) executes the method five times. It is commonly used to verify reliability, reproduce intermittent (flaky) failures, and simulate light load.

Pairing invocationCount with the threadPoolSize attribute lets those repeated runs execute in parallel across multiple threads. For a full reference, see the TestMu AI guide to TestNG annotations.

Understanding invocationCount in TestNG

invocationCount is an optional attribute of the @Test annotation. Its default value is 1, meaning every test runs once unless told otherwise. Increasing it instructs TestNG's runner to invoke the annotated method repeatedly within a single test run and to report each invocation as a separate result. This is different from re-running a whole suite; it repeats one method in place, which makes it a lightweight way to expose non-deterministic behavior.

Because a passing test can sometimes succeed by chance, running it many times gives far more confidence than a single execution. If any of the repetitions fail, TestNG surfaces the failure, helping you catch race conditions and timing issues that would otherwise slip through.

Basic Example: Repeating a Test

If a test method needs to run five times to confirm its reliability, add invocationCount=5 to the annotation. TestNG then calls the method five times:

import org.testng.Assert;
import org.testng.annotations.Test;

public class CalculatorTest {

    @Test(invocationCount = 5)
    public void testAddition() {
        Calculator calc = new Calculator();
        int result = calc.add(2, 3);
        Assert.assertEquals(result, 5);
    }
}

The TestNG report shows testAddition executed five times. Each invocation is counted independently, so you immediately see whether the method is consistently green or occasionally flaky.

Running Invocations in Parallel With threadPoolSize

To run the repetitions concurrently, add threadPoolSize. TestNG then distributes the invocations across the specified number of threads, which is useful for load and concurrency testing. Note that threadPoolSize is ignored unless invocationCount is also set.

@Test(invocationCount = 10, threadPoolSize = 3, timeOut = 10000)
public void testUnderLoad() {
    Calculator calc = new Calculator();
    Assert.assertEquals(calc.add(2, 3), 5);
}

Here the method runs ten times, spread across three parallel threads, with a per-invocation timeout of ten seconds. You can also use invocationTimeOut to cap the total time all invocations may take together.

Common Use Cases and Related Attributes

• Reliability checks: Repeat a test many times to confirm it is stable, not passing by luck.
• Flaky test reproduction: A high invocationCount surfaces intermittent failures that a single run misses.
• Lightweight load testing: Combine with threadPoolSize to simulate concurrent users hitting the same code.
• invocationTimeOut: Caps the total time for all invocations combined, failing the test if exceeded.
• successPercentage: Lets a test pass when a defined percentage of invocations succeed, tolerating known flakiness.

Common Mistakes and Troubleshooting

• Setting threadPoolSize alone: Without invocationCount, threadPoolSize is ignored and the test runs only once.
• Shared mutable state: Parallel invocations that touch shared fields cause race conditions; keep test logic thread-safe.
• Misreading successPercentage: Combining it with parallel invocations can mask real failures, so use it deliberately.
• Confusing repetition with retries: invocationCount always runs x times; it is not a retry-on-failure mechanism like IRetryAnalyzer.
• Ignoring data providers: With a data provider, total runs equal invocationCount times the number of data rows, which can explode unexpectedly.

Run TestNG Tests Across 3000+ Browsers and Devices

invocationCount proves a test is stable on one machine, but real reliability means proving it across the browsers and operating systems your users run. With TestMu AI, you can execute your TestNG and Selenium suites in parallel across 3000+ real browsers, operating systems, and device combinations. Point your WebDriver at the cloud grid, run repeated and parallel invocations concurrently to cut execution time, and capture logs, screenshots, and videos for every run, turning invocationCount reliability checks into full cross-browser testing coverage through the TestMu AI automation testing platform.

Conclusion

The @Test(invocationCount=x) annotation is a simple but powerful way to run a TestNG method multiple times, exposing flaky behavior and building confidence in test reliability. Paired with threadPoolSize, invocationTimeOut, and successPercentage, it also enables lightweight load and concurrency testing. Combine it with a cloud grid, and those repeated runs validate your application across every browser and device your users depend on.

Frequently Asked Questions

What does invocationCount do in TestNG?

invocationCount is a @Test attribute that tells TestNG how many times to run a test method. For example, @Test(invocationCount=5) executes the method five times in a row, which is useful for reliability checks, load simulation, and catching intermittent failures.

How do invocationCount and threadPoolSize work together?

threadPoolSize sets how many threads run the invocations in parallel. Combined with invocationCount, TestNG distributes the repeated runs across those threads. threadPoolSize is ignored unless invocationCount is also specified, so both are needed for parallel repetition.

What is the default value of invocationCount?

The default value of invocationCount is 1, meaning a test method runs once unless you set a higher value. Setting invocationCount to a number greater than one makes TestNG repeat the method that many times.

What is invocationTimeOut in TestNG?

invocationTimeOut sets the maximum total time, in milliseconds, that all invocations of a test method together may take. If the combined runs exceed that limit, TestNG marks the test as failed. It is meaningful only when used with invocationCount.

When should I use invocationCount?

Use invocationCount to verify a test is stable across repeated runs, to reproduce flaky failures, or to perform lightweight load and concurrency testing when paired with threadPoolSize. It helps confirm consistent behavior rather than a single lucky pass.

Does invocationCount work with data providers?

Yes. When a test uses a data provider, invocationCount multiplies the runs: the method executes invocationCount times for each set of data the provider supplies, so the total number of executions is invocationCount times the number of data rows.

• What is the use of @Test(threadPoolSize=x)?
• What does the test timeout mean in TestNG?
• What are the major features of TestNG?
• How to create a test suite in Eclipse?
• What is Selenium WebDriver?