You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems that ExecutionMode.CONCURRENT does not wait for everything in the class to complete before executing tests in other classes.
I was trying to parallelize a test for a query to retrieve from a database, but this behavior corrupted the test data and did not produce the expected results.
Is it possible to add a mode where execution within a class is parallelized, but execution of all tests within the class waits for completion?
As far as I have tried, it seems to be possible to achieve this behavior by giving @Execution(ExecutionMode.CONCURRENT) to the inner class and preparing an empty AfterAll in the outer class.
The following is the structure when reproduced (it was actually Kotlin).
However, when this was done, it seemed that execution via gradle would result in a normal exit even though there were tests that had not yet been processed.
I am sorry that I have not been able to reproduce the problem at a minimum, but I am reporting this once in consideration of the possibility of a bug.
I have reproduced it at least with 5.10.2 and 5.10.3.
The text was updated successfully, but these errors were encountered:
However, when this was done, it seemed that execution via gradle would result in a normal exit even though there were tests that had not yet been processed.
Are you using an include/exclude pattern in your Gradle config that caused the outer class to be excluded?
If you want to run all classes sequentially, but tests within a class concurrently, you can use the following configuration parameter settings:
Unfortunately this did not help.
In my use case, not all classes can be executed concurrently in the same way.
This means that it is difficult to use an option that would apply equally to all classes.
On the other hand, there does not appear to be a way to apply the same behavior as the option you gave me to only one class.
As far as I have tried the inner class, it does not appear to wait on the entire outer class, even when it is granted to the inner class.
As I tried later, the method of applying it to each test method seemed to work, but I would like to avoid this as it would be too much work.
(As a side note, this also has not been applied due to a bug that I reported separately that causes it to exit midstream.)
Are you using an include/exclude pattern in your Gradle config that caused the outer class to be excluded?
No.
The only difference from normal execution is that junit.jupiter.execution.parallel.enabled is true and @Execution(ExecutionMode.CONCURRENT) is given to a specific internal class or method.
@k163377 I'm afraid it's close to impossible to discuss this without a concrete example. If you could post a reproducer that illustrates the problem, I'd be happy to take a look.
It seems that
ExecutionMode.CONCURRENT
does not wait for everything in the class to complete before executing tests in other classes.I was trying to parallelize a test for a query to retrieve from a database, but this behavior corrupted the test data and did not produce the expected results.
Is it possible to add a mode where execution within a class is parallelized, but execution of all tests within the class waits for completion?
As far as I have tried, it seems to be possible to achieve this behavior by giving
@Execution(ExecutionMode.CONCURRENT)
to the inner class and preparing an emptyAfterAll
in the outer class.The following is the structure when reproduced (it was actually
Kotlin
).However, when this was done, it seemed that execution via
gradle
would result in a normal exit even though there were tests that had not yet been processed.I am sorry that I have not been able to reproduce the problem at a minimum, but I am reporting this once in consideration of the possibility of a bug.
I have reproduced it at least with
5.10.2
and5.10.3
.The text was updated successfully, but these errors were encountered: