Support multiple `junit-platform.properties` on the classpath

[famod]

I implemented a ClassOrderer for Quarkus and the idea was to enable that orderer by default for all Quarkus users (and also for the Quarkus CI).
But I overlooked the fact that junit-platform.properties is only expected once on the classpath and if there already is a project-specific properties file (e.g. with junit.jupiter.extensions.autodetection.enabled) there are many warnings issued by this code: https://github.com/junit-team/junit5/blob/r5.8.2/junit-platform-launcher/src/main/java/org/junit/platform/launcher/core/LauncherConfigurationParameters.java#L232-L236

Btw, that orderer is configurable, so the original idea also was to just add (as a Quarkus user) a custom junit-platform.properties to your project with only the respective property (without repeating junit.jupiter.testclass.order.default).

It would come in very handy if all junit-platform.properties on the classpath would be merged, in the order as they appear on the cp.
I'm not sure whether a flag to go back to the previous behavior would be required, which is a bit of a chicken and egg situation I guess (where to put it?).

[famod]

(I think the bot has mistakenly picked up the IntelliJ IDEA label because I merely used the word "idea".)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. Thank you for your contribution.

[stefanrybacki]

Unstale

[famod]

Hi @marcphilipp, may I ask whether the team had time to discuss this?

[mpkorstanje]

Note: Not part of the JUnit team.

It seems to me that depending on the classpath order to determine the configuration of JUnit is fraught with unpredictability and would make it hard to reason about the effective configuration.

However the JUnit Platform accepts configuration from a few different sources, the properties file being only one of them.

Now I'm not familiar with Quarkus but I would expect that all projects inherit from some parent-pom. Have you considered providing the property through Surefire instead?

[famod]

Now I'm not familiar with Quarkus but I would expect that all projects inherit from some parent-pom. Have you considered providing the property through Surefire instead?

There is no parent pom in Quarkus but a BOM instead (which cannot transport plugin config).
Generated apps could be covered this way, but:
a) not everyone uses that generation
b) there are many existing projects out there
c) surefire config is not picked automatically in Eclipse IDE (and maybe others)

PS: ...and there is also Gradle.

[marcelstoer]

We were just bitten by this as well. Our project (transitively) depends on io.quarkus:quarkus-junit5-properties which ships a junit-platform.properties (source). This now clashes with our own file.

#replaces the need to set @TestInstance(TestInstance.Lifecycle.PER_CLASS) on every test class
junit.jupiter.testinstance.lifecycle.default=per_class

It seems to me that depending on the classpath order to determine the configuration of JUnit is fraught with unpredictability

👍

This is particularly so as the JUnit guide warns "It is therefore recommended to change the default in the JUnit Platform configuration file instead of via a JVM system property."

At the moment, the only sensible remedy appears to be to exclude the Quarkus dependency and to copy-paste their JUnit instructions into our junit-platform.properties.