junit5 runner doesn't support parallelism via forking

[oldium]

I am not sure whether this is technically possible, but when I run Spring Boot tests on a Java project via Maven, when the tests are in a module named my-module, and with the following configuration using JVM forks and reusing:

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <configuration>
                    <environmentVariables>
                        <TESTCONTAINERS_REUSE_ENABLE>false</TESTCONTAINERS_REUSE_ENABLE>
                    </environmentVariables>
                    <forkCount>3</forkCount>
                    <reuseForks>true</reuseForks>
                    <workingDirectory>${project.basedir}</workingDirectory>
                    <systemPropertyVariables>
                        <user.dir>${project.basedir}</user.dir>
                    </systemPropertyVariables>
                </configuration>
            </plugin>

I see error during tests startup:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.5.4:test (default-test) on project my-app: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:3.5.4:test failed: org.apache.maven.surefire.api.util.SurefireReflectionException: java.util.ServiceConfigurationError: org.junit.platform.launcher.TestExecutionListener: Provider com.diffplug.selfie.junit5.SelfieTestExecutionListener could not be instantiated: Could not find a standard test directory, 'user.dir' is equal to C:\Users\work\Projects\my-app, looked in [src/test/java, src/test/kotlin, src/test/groovy, src/test/scala, src/test/resources] -> [Help 1]

All the tests are actually inside a module C:\Users\work\Projects\my-app\my-module.

I tried to find the root cause, but I am not expert (neither Kotlin nor Maven), so please bear with me. The debug output of Maven looks good, the user.dir is being set, but it is not recognised by Selfie. Possible cause is that SnapshotSystemJUnit5 is a static object, so it might get initialized before the JUnit5 in a forked JVM updates the working directory and sets system property user.dir to the expected value.

[nedtwigg]

Hopefully this is just a matter of figuring out the working directory correctly. I'm a little worried that maybe each fork has its own SnapshotSystemJUnit5 and we'll need to figure out some method of merging them at the end of the test run.

As a workaround, Selfie is known and tested to work great on parallel builds without forking.

[oldium]

There are separate instances of SnapshotSystemJUnit5, but the forked parallelism is on the class level, so concurrent file access from multiple forks should not happen.