TestNG 7.9.0 released!!!

[⇜Krishnan Mahadevan⇝]

Hello everyone,

On behalf of the TestNG Dev team,I am pleased to announce the availability of TestNG 7.9.0 org.testng:testng:7.9.0

TestNG 7.9.0 is now available in Maven Central.

Contributors who helped make TestNG become better in this release:

• Alex Heneveld
• dr29bart
• Mohsin Sackeer
• Pavlo Glushchenko

Special thanks go to:

• Julien Herr for helping out with all the code reviews 
• To all the other contributors who made this release possible. 

In this release, we spent time squashing some bugs (Please see below for a full list of issues that were fixed)

• GITHUB-2019: Total thread count in testng parallel tests with dataproviders
• GITHUB-3006: ITestResult injected at @AfterMethod incorrect when a configuration method failed
• GITHUB-2980: Data Provider Threads configuration in the suite don’t match the documentation
• GITHUB-3003: BeforeClass|AfterClass with inheritedGroups triggers cyclic dependencies
• GITHUB-2991: Suite attributes map should be thread safe
• GITHUB-2974: Command line arguments -groups and -excludegroups override defined groups in a suite xml file
• GITHUB-2961: “Unexpected value: 16” error when multiple beforeMethod config methods with firstTimeOnly property run before a test
• GITHUB-2904: Add location of docs Github to readme and contributions page
• GITHUB-2934: Parallel Dataproviders & retries causes test result count to be skewed
• GITHUB-2925: Issue in ITestcontext.getAllTestMethods() with annotation @BeforeSuite
• GITHUB-2928: The constructor of TestRunner encountered NBC changes in 7.8.0
• GITHUB-581: Parameters of nested test suites are overridden
• GITHUB-727 : Fixing data races
• GITHUB-2913: Maps containing nulls can be incorrectly considered equal
• Added @Inherited to the Listeners annotation, allowing it to be used in forming meta-annotations.

We also pushed in some interesting new features into this release.

Shared thread pool amongst all data driven tests in a Suite

Traditionally TestNG spins off a data driven test in its own thread pool.

Lets say we have the following as a scenario: 

• There are two driven tests.
• Each test has a data set of size 3.
• Parallelism has been configured as parallel="methods" in the <suite>.
• Data provider is configured to run in parallel.
• Data provider thread count is defined as “3”.

For this scenario, TestNG would spin off totally 6 threads.

This becomes more complex when we have a lot of data driven test methods and we would like to control our parallel execution.

We can now instruct TestNG to share a common thread pool across all data driven tests using one of the two approaches:

• via TestNG configuration parameter -shareThreadPoolForDataProviders true
• via the suite xml attribute share-thread-pool-for-data-providers=true [ Remember to update your suite file to point to the newer DTD at https://testng.org/testng-1.1.dtd ]

With this new configuration enabled and for the above scenario, TestNG will always spin off ONLY 3 threads for the entire suite ( because that’s the thread pool size defined via the data provider thread count attribute ) and run the 6 methods ( 2 methods with 3 iterations each) in this global thread pool of size 3.

For more information, please refer to the official documentation

Shared thread pool amongst all data driven & regular tests in a Suite

TestNG now allows you to configure it to use a common thread pool which will be shared amongst both your regular test methods and your data driven test methods for a given <suite>. This can be done via one of the below two approaches:

• via TestNG configuration parameter -useGlobalThreadPool true
• via the suite xml attribute use-global-thread-pool=true [ Remember to update your suite file to point to the newer DTD at https://testng.org/testng-1.1.dtd ]

Lets say we have the following as a scenario: 

• There are two tests (One regular test and one data driven test).
• The data driven test has a data set of size 3.
• Parallelism has been configured as parallel="methods" in the <suite>.
• Data provider is configured to run in parallel.
• Thread count is defined as “3”.

With this new configuration enabled and for the above scenario, TestNG will always spin off ONLY 3 threads for the entire suite ( because that’s the thread pool size defined via the thread count attribute ) and run the 4 methods ( 1 method with 3 iterations and 1 regular method) in this global thread pool of size 3.

For more information, please refer to the official documentation

Remember: When using this feature, you need to ensure that you have a properly sized thread pool for running your tests (both regular and data driven tests), else your tests may stall for a long time.

Note:

For both these two new features to work it’s important that we run with the custom thread pool implementation in TestNG as disabled. From this release onwards the custom thread pool implementation [ which can be turned ON via the JVM argument -Dtestng.favor.custom.thread-pool.executor=true ] should be disabled. This implementation is going to go away in the next release and its existence shouldn’t be evident to your regular executions.

Thanks & Regards
Krishnan Mahadevan

"All the desirable things in life are either illegal, expensive, fattening or in love with someone else!"
My Scribblings @ http://wakened-cognition.blogspot.com/

My Technical Scribblings @ https://rationaleemotions.com/