Test run wrong order when use DependsOnGroups and Parallel by classes

[hieuhth]

Test run wrong order when use DependsOnGroups and Parallel by classes

[juherr]

Related to #2372

[krmahadevan]

@hieuhth - What version of TestNG are you working with ?

I tried using 7.8.0 and I am not able to reproduce the issue. Please try using the latest version and post back your findings

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
...
... TestNG 7.8.0 by Cédric Beust ([email protected])
...

Run FirstTest3 Mon Sep 25 16:58:38 IST 2023
Run FirstTest2 Mon Sep 25 16:58:38 IST 2023
Run FirstTest1 Mon Sep 25 16:58:38 IST 2023
Run SecondTest2 Mon Sep 25 16:58:43 IST 2023
Run SecondTest1 Mon Sep 25 16:58:43 IST 2023
Run SecondTest3 Mon Sep 25 16:58:43 IST 2023

===============================================
Test Suite
Total tests run: 6, Passes: 6, Failures: 0, Skips: 0
===============================================

[hieuhth]

@krmahadevan I use testng 7.8.0.

I have just rechecked, I set JAVA_TOOL_OPTIONS -Dtestng.thread.affinity=true (to resolve a other issue in my project).

If I remove this config, issue will not occur.
How to use this config without issue which I posted?

[krmahadevan]

Great. Then i guess we can close this issue @hieuhth ?

[hieuhth]

@krmahadevan I don't think so.

testng.thread.affinity : resort to running dependent methods on the same thread as the upstream method

-> I think we should only resort methods of same class when run parallel by classes, and depend is used.

[krmahadevan]

@hieuhth

testng.thread.affinity : resort to running dependent methods on the same thread as the upstream method

A couple of things about this feature

• This is an experimental feature.
• This works ONLY when you have EXACTLY 1 upstream method.

-> I think we should only resort methods of same class when run parallel by classes, and depend is used.

I don't think that's possible. It can be done in a limited fashion when you use the above mentioned JVM argument, but this cannot be used as a generalised strategy. I say this because upstream can always be more than 1 method and so its not going to be possible to figure out on which thread to run a dependent method, when it has more than 1 upstream dependencies.

I would suggest that you relook at your tests. Having a thread affinity in tests kind of sounds like a code smell. I am guessing you are resorting to this because you are having some sort of a dependency on a thread local variable. I would suggest that you re-look at your approach and either resort to building customisations that would ensure that the same thread local variable gets copied over to the dependent thread (or) you remove that dependency completely from your test.

The plain vanilla execution of dependsOngroups and parallel running works fine without any issues. The experimental thread affinity feature was never guaranteed to work for all use cases. It was meant to work ONLY for a specific use case, wherein you have a method that depends on exactly 1 upstream. Also the side effects of this behaviour when coupled with other hard ordering features (such as dependsOnGroups) is NOT documented.