Is EnhancedLegacyXmlReportGeneratingListener TestExecutionListener thread-safe?

[adicusar-lh]

I have been running JUnit 5 tests with gradle having following settings (maxParallelForks as example with 2):

useJUnitPlatform() {
        maxParallelForks = getParallelThreads()
        ...
    }

And saw that when I have uploaded .xml extended report to Xray instead of 3 tests there were only 1 or 2 (tried multiple times) results shown. It means that probably different threads had simultaneously written to the .xml report and could overwrite the contents.

So are there any recommendations? Maybe to use parallelisation from JUnit 5 side only?

[bitcoder]

Hmm but are you generating more than one Junit XML report? The fact that the tests run in parallel should not affect the number of reports I would say (unless specified otherwise). Can you try generating the standar JUnit XML report without these enhancements, using the builtin legacy XML reporter and check its behavior?

[adicusar-lh]

In my case, I have registered an extension via metainf and use XrayTest annotation with test methods. And yes, I have always generated and used only 1 report. I'll try to use JUnit 5 parallelisation and get back with results. Maybe gradle has something to do with it.

[bitcoder]

Btw, the EnhancedLegacyXmlReportGeneratingListener is mostly based on the LegacyXmlReportGeneratingListener from Junit so it probably inherits its behaviour.

[adicusar-lh]

@bitcoder I have used JUnit 5 parallelisation with following parameters (parallelism parameter was 2 or 3 as example)

junit.jupiter.extensions.autodetection.enabled=true
junit.jupiter.execution.parallel.enabled = true
junit.jupiter.execution.parallel.mode.default = same_thread
junit.jupiter.execution.parallel.mode.classes.default = concurrent
junit.jupiter.execution.parallel.config.strategy=fixed
junit.jupiter.execution.parallel.config.fixed.parallelism=2

and everything worked fine, report had all the tests (I have divided 3 tests into 3 classes, 1 test per class). The only thing needed comparing to Gradle approach was to ensure that some resources are accessed in proper way due to parallel threads. With Gradle approach it was like having each separate VM and each one was writing to the .xml

So as long as you use JUnit 5 parallelisation you are good.

I'll close that issue.