How to use UniAsserter with QuarkusComponentTest ?

[cvgaviao]

I would like to unit test some service methods that I use on endpoints that returns uni.

I was able to setup an QuarkusComponentTest based test that is mocking the repositories and some other required components and injecting the service well.

    @RegisterExtension
    static final QuarkusComponentTestExtension extension = new QuarkusComponentTestExtensionBuilder()
            .addComponentClasses( MyService.class)
            .build();

To assert uni result I know that I can use UniAsserter as I do with tests using @QuarkusTest. But I don't know if I need to do anything more to use it while using @QuarkusComponentTest.

What am I missing ?

2024-09-07 15:31:29,350 INFO  [io.qua.tes.com.QuarkusComponentTestExtension] (main) No matching bean found for the type [interface io.quarkus.test.vertx.UniAsserter] and qualifiers [] - consider annotating the parameter with @SkipInject

org.junit.jupiter.api.extension.ParameterResolutionException: No ParameterResolver registered for parameter [io.quarkus.test.vertx.UniAsserter asserter] in method [void com.MyServiceTest.testWithService(io.quarkus.test.vertx.UniAsserter)].
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)

[mkouba]

The UniAsserter is not supported in QuarkusComponentTest yet. In theory, you could just instantiate an io.quarkus.test.vertx.DefaultUniAsserter and use it in your test but keep in mind that things like Hibernate Reactve Panache would not work anyway becase they need a running Quarkus app which is not the case of QuarkusComponentTest where only the CDI container (ArC) is started.

[mkouba]

Actually, manual instantiation would not be enough. Because you also need to subscribe to the underlying Uni. And this part of the API is not exposed to users :-(

This should work:

uniAsserter.asUni().await().indefinitely();

[E14]

It's 2026... Do you know, has the situation improved?

I'm currently trying to implement tests within Mutiny, but would really like to avoid starting a full quarkus instance for every test.

My basic issue with your suggestion is that awaiting on the test thread (which is effectively what uniAsserter...await().indefinitely() does) behaves significantly differently to running on vertx, especially concerning code that runs the @Blocking fencing stuff, so I would like to at least run on a vertx that is as close as possible to how quarkus configures it

[mkouba]

Well, QuarkusComponentTest does not run Vert.x 🤷.

that runs the @Blocking fencing stuff,...

Not sure what this means but if you really need to run the test in an environent that as close as possible to the production mode then just use the @QuarkusTest; note it does not start a full Quarkus instance for every test, the instance is reused for all tests, unless the configuration is changed via TestProfile. Basically, all tests that share the same test profile share the same Quarkus instance.

[E14]

Thanks for taking the time to reply - I'm aware of those options. I was hoping for something like a vertx "component" that could be added to a component test.

Not sure what this means

The actual internal API/logic used changes all over, or maybe available APIs have changed over time, but the goal is always to prevent running "blocking" code on an IO thread, like here

quarkus/extensions/resteasy-classic/resteasy/runtime/src/main/java/io/quarkus/resteasy/runtime/standalone/VertxBlockingOutput.java

Lines 149 to 151 in 05c9278

	if (Context.isOnEventLoopThread()) {
	throw new BlockingOperationNotAllowedException("Attempting a blocking write on io thread");
	}

(I know this is in resteasy-classic, that's just the first I found within Quarkus, pretty sure there are many places in vertx where similar tests are done)

[mkouba]

Now I understand what you mean. Unfortunately, a Vert.x component would not be enough. It's the integration with other extensions that's important here.

I'd recommend to write the QuarkusComponentTests in a way that the execution model does not matter. I know that it might be easier to said than done 🤷.

[RinZ27]

The maintainer answer from @mkouba is correct — UniAsserter is not wired into QuarkusComponentTest because it requires the full Vert.x event loop infrastructure that only spins up with @QuarkusTest.

Here are the practical options:

Option 1: Use DefaultUniAsserter directly (simplest)

@QuarkusComponentTest
class MyServiceTest {

    @Inject
    MyService service;

    @Test
    void testReturnsExpectedResult() {
        var asserter = new io.quarkus.test.vertx.DefaultUniAsserter();
        asserter.assertThat(
            () -> service.findById(1L),
            dto -> Assertions.assertThat(dto.name()).isEqualTo("expected")
        );
        asserter.execute();
    }
}

DefaultUniAsserter.execute() runs the assertions synchronously using a blocking subscriber — safe to use in unit tests since there is no event loop to block.

Option 2: Block directly with .await().indefinitely() (for simple cases)

Since QuarkusComponentTest does not run on an event loop thread, blocking is safe:

@Test
void testMyService() {
    MyDto result = service.findById(1L)
        .await().indefinitely();
    assertThat(result.name()).isEqualTo("expected");
}

This is the most readable approach and perfectly fine in the QuarkusComponentTest context.

Option 3: Switch to @QuarkusTest with mocks (if you need reactive infra)

If your service uses Hibernate Reactive, Panache reactive, or anything that needs the actual Vert.x event loop, @QuarkusTest + Mockito mocks on the repository layer is the correct path. QuarkusComponentTest intentionally omits that infrastructure.

Bottom line: for pure CDI/logic unit tests, Option 2 (.await().indefinitely()) is the cleanest and most idiomatic. Reserve @QuarkusTest for integration-level tests that need the full runtime.