omatheusmesmo opened a new issue, #3529: URL: https://github.com/apache/maven-surefire/issues/3529
### Affected version 3.6.0 (maven-surefire-plugin and maven-failsafe-plugin). The code on master behaves the same way. ### Bug description Reported downstream in https://github.com/quarkusio/quarkus/issues/57084. Since 3.6.0, `JUnitPlatformProvider.setupRunOrder()` maps the `runOrder` option to JUnit Jupiter ordering parameters and stores them with an unconditional `put` in the explicit configuration parameters: - `random` -> `junit.jupiter.testclass.order.default=ClassOrderer$Random` and `junit.jupiter.testmethod.order.default=MethodOrderer$Random` - `alphabetical` -> `ClassOrderer$ClassName` and `MethodOrderer$MethodName` - `reversealphabetical` -> `ReverseOrdering$ReverseClassOrder` and `ReverseOrdering$ReverseMethodOrder` Explicit parameters take precedence over system properties and `junit-platform.properties`, so any orderer that a library or the user configured through those sources is silently replaced when `runOrder` is set. Setting the same key through the `configurationParameters` plugin option does not help either: I checked that the `runOrder` mapping replaces it. Before 3.6.0, `runOrder` did not translate into these JUnit parameters, so projects that combined it with a library-provided default orderer kept working. A concrete case is Quarkus. `quarkus-junit` ships a `junit-platform.properties` that registers a `ClassOrderer` which groups test classes by test profile, because tests would otherwise run on an application that has already been shut down. With `<runOrder>alphabetical</runOrder>` and several `@QuarkusTest` classes using different `@TestProfile`, the Quarkus orderer is replaced by `ClassOrderer$ClassName` and the run fails. The Quarkus report is https://github.com/quarkusio/quarkus/issues/57084. Steps to reproduce: 1. Use `maven-surefire-plugin` 3.6.0 with `<runOrder>alphabetical</runOrder>`. 2. Add `quarkus-junit` and at least two test classes annotated with `@QuarkusTest` and different `@TestProfile` classes, whose names do not sort by profile. 3. Run `mvn test`. Expected: the orderer configured by the library (or by `configurationParameters`) is kept, or the user gets a way to say which one wins. Actual: the orderer is replaced by the one derived from `runOrder`. Suggestion: only set these parameters when the key is not already present in `configurationParameters`, and document the interaction, building on #3510. I have not checked whether the provider can also detect values that come from `junit-platform.properties` at that point, which is what the Quarkus case needs. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
