Support CompletionStage friendly method signature

[rmannibucau]

It is common to have promise friendly code - and virtual threads will not change that so much, at least for libs.

And all the time in code we do promise.get() to be able to comply to junit signature support.

Request is to enable to return a promise (@Test CompletionStage<?> myTest() { ... }).

This will enable to define the test code as most of the code base with promise related API and not have to block randomly sometimes leveraging better the CPU in concurrent mode.

Then junit runtome will try/catch around the test method as today but if result is a promise it will await it using whenComplete it to check if there is a failure or not.

The framework will guarantee all promises are done before exiting - as today implicitly.

[mpkorstanje]

It is common to have promise friendly code - and virtual threads will not change that so much, at least for libs.

From your description I get the impression that the test would be executed inside the promise. To avoid any ambiguity, could you provide a simple but non-trivial example of what this would look like?

[rmannibucau]

@Test
CompletionStage<?> mytest(MyTestHelper helper, MyInjectedService service) {
    return helper
       .init()
        .thenCompose(data -> service.compute(new Request(data.getXxx()))
        .thenApply(result -> assertAll( .... ));
}

so yes the "given, when, then" pattern is actually a chain of promises but as soon as you have > 1 promise it is worse it (previous snippet has only 2 levels but in practise projects embrassing completionstage pattern often make it even more composed).

Indeed having an assertAsync or alike can work but will have the drawback to block so still not leverage the machine CPU accurately whereas giving it back to the caller (framework/runtime) it enables to make it run faster.

[marcphilipp]

It is common to have promise friendly code - and virtual threads will not change that so much, at least for libs.

And all the time in code we do promise.get() to be able to comply to junit signature support.

I haven't come across this testing style in the wild. Is there an open source project that does this?

Then junit runtome will try/catch around the test method as today but if result is a promise it will await it using whenComplete it to check if there is a failure or not.

This is similar to the recent addition of coroutine support for Kotlin. There we wrap the suspend function in runBlocking to wait for it to complete before proceeding with the enclosing container (usually the test class and its @AfterAll etc. behavior).

We could do something like this if we decide to support CompletionStage-returning methods:

CompletionStage<?> returnValue = // call to test method via reflection
try {
	returnValue.toCompletableFuture().join()
} catch (CompletionException ex) {
	throw ex.getCause();
}

[rmannibucau]

I haven't come across this testing style in the wild. Is there an open source project that does this?

If you mean "block" yes - just a few examples:

• https://github.com/apache/johnzon (https://github.com/apache/johnzon/blob/master/johnzon-jsonlogic/src/test/java/org/apache/johnzon/jsonlogic/JohnzonJsonLogicTest.java#L115 - latch variant but get() would work)
• https://github.com/yupiik/fusion (https://github.com/yupiik/fusion/blob/master/fusion-http-server/src/test/java/io/yupiik/fusion/http/server/WebServerTest.java#L239 , all this class https://github.com/yupiik/fusion/blob/a01e046062f59f47514304f0ff3371a7c138ae98/fusion-testing/src/main/java/io/yupiik/fusion/testing/assertion/Asserts.java#L37 )
• more generally all awaitability consumers

The concept is pretty much 1-1 with what does NUnit using [Test] public async Task MyAsyncTest() (Task is the promise in .NET), see https://docs.nunit.org/articles/nunit/writing-tests/attributes/test.html

I assume spring team would like to support Mono and friends, while it can be done using a custom MyTest implementation, I think it can be worth it enabling to wire it at platform level otherwise you expose a nice API and not leverage it which there could be huge on suite execution time - even if it can need to be combined with locking extensions for some particular cases but generally speaking it will be worth it IMHO until virtual threads are everywhere and the API is made no more blocking style.

We could do something like this if we decide to support CompletionStage-returning methods:

As mentionned, I would prefer you think it the opposite way, ie wrap the current blocking execution in:

Executable testToExecute = ...;
Executor defaultPool = framework.getPool(); // idea not existing yet
CompletableFuture<?> promise = new CompletableFuture<Object>();
defaultPool.execute(() {
 try {
  testToExecute.call();
  promise.complete(null);
 } catch (Exception | Error e) {
  promise.completeExceptionaly(e);
 }
});
return promise;

so the framework always handles promises with a max test count (semaphore guarded for ex - default to int.max).