2

I'm using the new JUnit 5 concurrency feature to run multiples @SpringBootTest classes in parallel. It works great with a small test set but once I run all the tests classes, it's going to start multiple instances of my Spring Boot app. It's pretty easy to see in the logs (I'm using JHipster).

I'm pretty sure this isn't supposed to happen since I didn't find anything about this behavior in the JUnit/Spring Boot docs.

What is even weirder is that it seems to spawn new instances randomly. It starts with 2 at the beginning and new ones are getting spun up during the execution (which pauses while the server starts). However, it's always the same process ID as if instances were destroyed and recreated along the way... (see logs below)

Here's my config:

  • spring-boot: 2.3.8.RELEASE
  • junit-platform: 1.7.1
  • junit-jupiter: 5.7.1
  • Running tests on Windows 10 and IntelliJ IDEA 2020.2.4 (Community Edition) but same behavior happens with mvn test

junit-platform.properties configuration:

junit.jupiter.execution.parallel.enabled=true
junit.jupiter.execution.parallel.mode.default=concurrent
junit.jupiter.execution.parallel.mode.classes.default=concurrent
junit.jupiter.execution.parallel.config.strategy=fixed
junit.jupiter.execution.parallel.config.fixed.parallelism=4

All tests classes are annotated with the following:

@Import({ PostgresqlTestConfig.class, MailTestConfig.class, ServerContext.class, CaptchaTestConfig.class })
@SpringBootTest(classes = { MyApp.class }, webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@ActiveProfiles("prod")

In the logs, I can clearly see the SB app starting procedure multiples times:


        ██╗ ██╗   ██╗ ████████╗ ███████╗   ██████╗ ████████╗ ████████╗ ███████╗
        ██║ ██║   ██║ ╚══██╔══╝ ██╔═══██╗ ██╔════╝ ╚══██╔══╝ ██╔═════╝ ██╔═══██╗
        ██║ ████████║    ██║    ███████╔╝ ╚█████╗     ██║    ██████╗   ███████╔╝
  ██╗   ██║ ██╔═══██║    ██║    ██╔════╝   ╚═══██╗    ██║    ██╔═══╝   ██╔══██║
  ╚██████╔╝ ██║   ██║ ████████╗ ██║       ██████╔╝    ██║    ████████╗ ██║  ╚██╗
   ╚═════╝  ╚═╝   ╚═╝ ╚═══════╝ ╚═╝       ╚═════╝     ╚═╝    ╚═══════╝ ╚═╝   ╚═╝

:: JHipster   :: Running Spring Boot 2.3.8.RELEASE ::
:: http://jhipster.github.io ::

2021-03-30 23:47:08.593  INFO 7200 --- [Pool-1-worker-5] .w.w.w.r.a.JwtAuthenticationResourceTest : Starting JwtAuthenticationResourceTest on MSI with PID 7200 
...
... (initializing the context here, i.e embedded PostgreSQL, running Liquibase, etc...)
...
2021-03-30 23:48:54.811  INFO 7200 --- [Pool-1-worker-5] org.quartz.core.QuartzScheduler          : Scheduler quartzScheduler_$_MSI1617140910513 started.
2021-03-30 23:48:54.850  INFO 7200 --- [Pool-1-worker-5] .w.w.w.r.a.JwtAuthenticationResourceTest : Started JwtAuthenticationResourceTest in 106.911 seconds (JVM running for 118.405)

... Then a bit later ...


        ██╗ ██╗   ██╗ ████████╗ ███████╗   ██████╗ ████████╗ ████████╗ ███████╗
        ██║ ██║   ██║ ╚══██╔══╝ ██╔═══██╗ ██╔════╝ ╚══██╔══╝ ██╔═════╝ ██╔═══██╗
        ██║ ████████║    ██║    ███████╔╝ ╚█████╗     ██║    ██████╗   ███████╔╝
  ██╗   ██║ ██╔═══██║    ██║    ██╔════╝   ╚═══██╗    ██║    ██╔═══╝   ██╔══██║
  ╚██████╔╝ ██║   ██║ ████████╗ ██║       ██████╔╝    ██║    ████████╗ ██║  ╚██╗
   ╚═════╝  ╚═╝   ╚═╝ ╚═══════╝ ╚═╝       ╚═════╝     ╚═╝    ╚═══════╝ ╚═╝   ╚═╝

:: JHipster   :: Running Spring Boot 2.3.8.RELEASE ::
:: http://jhipster.github.io ::

2021-03-30 23:51:14.626  INFO 7200 --- [Pool-1-worker-3] c.w.w.security.AuthenticationFlowTest    : Starting AuthenticationFlowTest on MSI with PID 7200
...
...

I hope somebody encountered the same problem. I doubt it's a configuration issue since pretty much everything is out of the box here...

Thanks in advance for everyone's time !

Blockost
  • 493
  • 1
  • 7
  • 18

1 Answers1

2

After a long and tedious process of trial and errors, I figured it out and it's pretty simple.

It's in no way related to JUnit 5 or the parallel execution and it was already happening before I use it on the project. It's related to Spring Boot tests not reusing application context in some cases.

Further details there:

Once all my test classes are using the exact same context configuration, only one server/context is loaded and parallel execution is working well !

Blockost
  • 493
  • 1
  • 7
  • 18