Introduce LauncherInterceptor API

[marcphilipp]

Overview

In order to support use cases where test discovery and execution needs to be wrapped by third-party code, e.g. for using the Eclipse OSGi runtime this PR introduces LauncherInterceptor which can be registered using Java's ServiceLoader mechanism. The feature is opt-in via a new configuration parameter than can be set as a system property in order to avoid accidental usage via transitive dependencies.

---

I hereby agree to the terms of the JUnit Contributor License Agreement.

---

Definition of Done

• There are no TODOs left in the code
• Method preconditions are checked and documented in the method's Javadoc
• Coding conventions (e.g. for logging) have been followed
• Change is covered by automated tests including corner cases, errors, and exception handling
• Public API has Javadoc and @API annotations
• Change is documented in the User Guide and Release Notes
• All continuous integration builds pass

[sormuras]

Nice work, Marc! Will take a closer look later this week.

I already see a way to supersed this project, or at least make sormuras/junit-platform-isolator use this new feature. 🤔

[jbduncan]

Interesting! I'm guessing this feature could also be used to run logic that needs to run only once per test suite invocation?

[marcphilipp]

Yes, but LauncherSessionListener might be a better fit for that.

[holly-cummins]

Hi @marcphilipp, thanks for this. I'm having a play with the new capability for the Quarkus use case (as discussed in #2579 and #3028). Using sophisticated debug (system out printlns), I can see that the launcher interceptor is being invoked, and is calling currentThread.setContextClassLoader in the intercept method. The launcher interceptor is running nice and early, before any of my tests or test extensions.

I have an extension which implements InvocationInterceptor. In its interceptBeforeAllMethod, I check the classloader of the test class with extensionContext.getRequiredTestClass().getClassLoader(). I would expect it to be the classloader I set on the TCCL in the LauncherInterceptor, but it's not. Similarly, if I check invocationContext.getExecutable().getParameters() and look at the classloader of the parameters, they're the same as they would be if my interceptor wasn't there.

Am I doing something wrong, or was I just over-optimistic about how much would be changed by doing an interception? I do hope it's "I am doing something wrong," because we've been quite excited about in the Quarkus team about how this would allow us to eliminate some classloader hacks.

(We're already able to run the test class itself from a different classloader with the existing interceptors, just by making a new instance with Class.forName() on the new classloader, but the arguments we have to pass in to the 'new' class are loaded by the 'old' classloader, and we get argument type mismatches. )

[holly-cummins]

Actually, it's an interceptTestMethod override where I'm checking the test class's classloader.