Replace usage of deprecated JUnit APIs

[marcphilipp]

• Use JUnit's EngineTestKit for testing
• Refactor discovery to use JUnit's EngineDiscoveryRequestResolver

[marcphilipp]

For context, I noticed this while testing spring-modulith against a 6.0.0-SNAPSHOT version of JUnit in which some of the deprecated APIs had been deleted which caused the engine to fail.

[mp911de]

🥳 Thank you for your contribution. That's merged now.

[marcphilipp]

@mp911de Could you please double-check that my changes don't break anything? The tests in DiscoverySelectorResolverTests still pass but they don't seem to cover all scenarios.

[mp911de]

Checked against a few of my projects containing benchmarks. Jitpack has published new snapshots so your tests with Spring Modulith should pass now.

[marcphilipp]

The spring-modulith build now fails for a different reason:

org.junit.platform.commons.JUnitException: TestEngine with ID 'microbenchmark-engine' failed to execute tests
Caused by: java.lang.NoSuchMethodError: 'void org.junit.jupiter.engine.config.DefaultJupiterConfiguration.<init>(org.junit.platform.engine.ConfigurationParameters, org.junit.platform.engine.reporting.OutputDirectoryProvider)'
        at jmh.mbr.junit5.MicrobenchmarkEngine.execute(MicrobenchmarkEngine.java:52)

DefaultJupiterConfiguration is internal API, though. IIUC you're doing that to support ExecutionCondition Jupiter extensions for JMH benchmarks? I think a custom extension API would be more stable than trying to reuse the internals of Jupiter's.

[mp911de]

We're using quite a few internal APIs to reuse conditions. There has been once a ticket/thread discussion potential reuse but that didn't go anywhere because of complexity vs. benefits.

The config support makes heavy use of converters and defaulting. Such concerns aren't the core of this project yet necessary to leverage conditions. Implementing in this project bears always the risk of different defaults or different behavior leaving with the unclear choice of the lesser evil.

Chasing internal API changes seemed to be less problematic than duplicating code and following up with changes.