New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DependsOnMethods made parallel class use several threads #1185
Comments
Is it working as expected without the |
@juherr yes, only 1 thread was used when I removed
|
It's working fine also if I set |
Yes, the problem is located in GraphThreadPoolExecutor/DynamicGraph. But I don't know how to fix it for the moment. |
@juherr At least it's already good to know where the issue come from. Except remove the dependsOnMethods and refactor a bit my class, do you see a workaround? |
In fact, dependsOn with parallel class can not work together. If it worked before, it was a side effect of another issue :/ |
I don't understand why you said dependsOn with parallel class cannot work together. Indeed, in this paralell mode, all the test methods inside a class has to be run in the same thread, so it does not affect the dependsOn, this is the theory. |
In the current state, yes. But it is supposed to work ;) |
Hi @juherr Any update on this? I'm facing the same problem due to parallel execution with dependsOnMethod. I had a look to graph/GraphThreadPoolExecutor.java but it looks like my basic knowledge won't be enough here. Thank you! |
@mathias21 Nope, nothing new for the moment. Sorry. |
I think I've found a workaround to solve this problem. It takes 2 dependencies: with the max amount of devices you are going to use at the same time, and also forcing you to release the session during @afterclass method, but apparently it works. If you specify in your suite XML file "thread-count='2'", then you can define your suite as following:
It is not the best solution, but apparently runs your tests with proper sorting. |
@mathias21 Thx you for your workaround, but sadly in my case I cannot apply it. But at least I can see I'm not the only one using parallel and dependsOnMethod features 👍 |
i have the same problem with parallel=classes & using dependsOnMethod in one classe, and i do some prepare work using localThread var :(. it takes me a long time to find out the thread change. hope this bug could be fixed soon :) |
The similar problem happens when using priority. Described in #1066 |
@juherr |
Hi all Do we know if this is not happening in a concrete version? I'm also using 6.9.12. I believe this is a structural issue, not a punctual bug or typo, am I right? |
@sylvainbouxin "actively" is not the good word but it is on the top of the list and I planned to work on it unless someone has enough motivation. @mathias21 Exactly! There are some similar issues and the root cause is often |
@juherr nice challenge, indeed... |
@sylvainbouxin Nice! Feel free to send me emails if you need to exchange some extra things. |
@juherr, you said:
Can you elaborate on what the problem is exactly? |
@cbeust due to the edge between methods, dependsOn* methods are no more together in the free nodes list. Now, they are free one by one. |
@juherr |
Can you please prioritize this issue-fix @juherr |
@nevilp88 - Its not that this issue is not a priority. Its just that, we haven't gotten around to fixing this, mainly due to lack of sufficient time. Trust me, this is one of the biggest issues that still is in our plate for fixing. But since this is also a problem in the core of TestNG, its a bit tricky to change behavior and ensure that we don't break anything. There's just a handful bunch of us (to be honest, currently just me and @juherr) who are juggling with all issues and trying our best to get them fixed. Thanks for your understanding |
Hi, I'm just one more guy facing this issue |
Workarounds a problem where methods and after class run in different threads, which results filling the whole grid at some point. testng-team/testng#1185 Also changes the test report to be prettier.
Hi! Any updates? |
Any plans to fix this? |
Closes testng-team#89, testng-team#1050, testng-team#1066, testng-team#1173, testng-team#1185 This PR aims at assuring that methods that fall under the below two use cases, all run on the same thread when classes are being run in parallel: * @test methods in a class are ordered by priority * @test methods have a single dependency on another method using “dependsOnMethods” attribute. The thread affinity feature is supposed to be “experimental” and it can be turned on via the JVM argument : -Dtestng.thread.affinity=true This feature is turned off by default just to ensure that we don’t have any users experiencing un-usual behavior.
Closes testng-team#89, testng-team#1050, testng-team#1066, testng-team#1173, testng-team#1185 This PR aims at assuring that methods that fall under the below two use cases, all run on the same thread when classes are being run in parallel: * @test methods in a class are ordered by priority * @test methods have a single dependency on another method using “dependsOnMethods” attribute. The thread affinity feature is supposed to be “experimental” and it can be turned on via the JVM argument : -Dtestng.thread.affinity=true This feature is turned off by default just to ensure that we don’t have any users experiencing un-usual behavior.
Closes testng-team#89, testng-team#1050, testng-team#1066, testng-team#1173, testng-team#1185 This PR aims at assuring that methods that fall under the below two use cases, all run on the same thread when classes are being run in parallel: * @test methods in a class are ordered by priority * @test methods have a single dependency on another method using “dependsOnMethods” attribute. The thread affinity feature is supposed to be “experimental” and it can be turned on via the JVM argument : -Dtestng.thread.affinity=true This feature is turned off by default just to ensure that we don’t have any users experiencing un-usual behavior.
Fixed by #1783 |
Thx for the fix. The current changelog of the future release is pretty big. Can we expect quickly a new version? |
@thibaut-sticky I'm not sure we will release quickly because it will be a major release and we want to take enough time to change/break everything we want/need without waiting for the next major release. |
add parallel execution testng-team/testng#1185 testng-team/testng#1783
@krmahadevan If I am not mistaken issue was fixed. But I am still able to reproduce it in 7.0.0-beta1. |
I dont think this was ever fixed, however 7.0.0 reverts whichever fix you attempted to do. We moved away from testng as our testsuite was growing and we couldnt afford not being able to use parallel exeuction. I did test our old codebase that was still using testng with 7.0.0 and the issues keeps happening. |
When using TestNG If even after doing that this issue is still occurring, please help share a sample that can be used to reproduce this issue. |
@krmahadevan works for me with |
I have come across an issue. import org.testng.annotations.Test;
public class TestClass2 {
@Test()
public void test0(){
System.out.println("TestClass2 - test0. Thread " + Thread.currentThread().getId());
}
@Test
public void test1() {
System.out.println("TestClass2 - test1. Thread " + Thread.currentThread().getId());
}
@Test(dependsOnMethods = "test1")
public void test2() {
System.out.println("TestClass2 - test2. Thread " + Thread.currentThread().getId());
}
@Test(dependsOnMethods = "test2")
public void test3() {
System.out.println("TestClass2 - test3. Thread " + Thread.currentThread().getId());
}
@Test()
public void test4(){
System.out.println("TestClass2 - test4. Thread " + Thread.currentThread().getId());
}
} and then tried to run through xml like this : <suite name="Default Suite">
<test name="testNG tests" parallel="classes" thread-count="50" >
<classes>
<class name="ie.kbc.qa.seleniumT24.debugs.TestClass2"/>
</classes>
</test>
</suite> I got an exception :
This exception is thrown when there is more then one test with no dependOnMethods |
@FredVaugeois - I would suggest that you please open up a new issue and include a sample that can be used to reproduce the problem. |
TestNG Version
Expected behavior
When setting TestNG to run tests in parallel by class, all the tests in a single class should be run in the same thread.
Actual behavior
If one of the test method depends on another, a new thread is created, which is really annoying for Selenium case for instance (BeforeClass open the browser, AfterClass kill it)
Test case sample
What I've tried:
The text was updated successfully, but these errors were encountered: