Introduce ParallelExecutionInterceptor and sample implementation

[marcphilipp]

The new junit.jupiter.execution.parallel.config.interceptor.class
configuration parameter allows configuring the fully qualified class
name of a ParallelExecutionInterceptor implementation that gets called
for each executed TestTask. The FixedThreadPoolForTests sample
implementation uses a separate fixed thread pool to run all tasks of
type TEST with execution mode CONCURRENT in.

Resolves #3108.

---

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

[mpkorstanje]

The FixedThreadPoolForTests sample implementation uses a separate fixed thread pool to run all tasks of type TEST with execution mode CONCURRENT in.

While this solves the specific problem, the implementation feels incomplete. Is that intentional?

When using a fixed thread pool, for each subtrees that must be executed on the same thread, I would expect that a thread from the thread pool is used for that entire subtree. With tasks of the type tests as the trivial case.

Edit: wording for clarity.

[marcphilipp]

When using a fixed thread pool, for each subtrees that must be executed on the same thread, I would expect that a thread from the thread pool is used for that entire subtree. With tasks of the type tests as the trivial case.

Since tests using ExecutionMode.CONCURRENT can be registered dynamically at runtime, we could only compute this value reliably if all TestDescriptors in the subtree returned false from their mayRegisterTests() methods. I guess we would restrict dynamic children to use SAME_THREAD regardless of what they return but we can't do so in general because that would be a regression. Thoughts?

[mpkorstanje]

I was under the impression that the NodeExecutionAdvisor would force the execution mode of all descendants to SAME_THREAD. So all dynamic children are already have the SAME_THREAD execution mode if any of their ancestors have SAME_THREAD regardless of their own execution mode.

[marcphilipp]

I was under the impression that the NodeExecutionAdvisor would force the execution mode of all descendants to SAME_THREAD.

It only does so if exclusive resource / resource locks are used.

[mpkorstanje]

Would it be possible to create a dummy task that calls invokeAll and submit that task instead?

[mpkorstanje]

Ah. No then SAME_THREAD won't work.

[mpkorstanje]

But what if only the call to joinConcurrentTasksInReverseOrderToEnableWorkStealing(concurrentTasksInReverseOrder); is submitted?

[mpkorstanje]

I guess we would restrict dynamic children to use SAME_THREAD regardless of what they return

What if, upon encountering DYNAMIC children, execution goes back to the ForkJoinPoolHierarchicalTestExecutorService again, and then invokes the ParallelExecutionInterceptor for each task as needed?

[mpkorstanje]

To clarify what I meant by incompleteness. When using junit.jupiter.execution.parallel.config.interceptor.class I would expect that it is possible to invoke all methods without a fork join pool. Not just the concurrent test methods methods but also the before all and same thread annotated methods.

Expressed as a test case:

@Execution(CONCURRENT)
static class ExampleTest {
	
	final static ThreadLocal<Integer> threadLocal = new ThreadLocal<>();

	@BeforeAll
	static void initialize() {
		assertThat(Thread.currentThread().getName()).doesNotStartWith("ForkJoinPool");
		threadLocal.set(42);
	}

	@Test
	@Execution(SAME_THREAD)
	void firstTest() throws Exception {
		assertThat(Thread.currentThread().getName()).doesNotStartWith("ForkJoinPool");
		assertEquals(42, threadLocal.get());
	}

	@Test
	void secondTest() throws Exception {
		assertThat(Thread.currentThread().getName()).doesNotStartWith("ForkJoinPool");
		assertNull(threadLocal.get());
	}
}

But I haven't quite got the time to try out my suggestions in code and see if they would actually work as expected.. Apologies for that.