@QuarkusIntegrationTest best practices

[nahguam]

Reading through the guides and javadoc it seems the recommended approach for @QuarkusIntegrationTest is to have a normal test base class and then extend it for the IT. This seems sensible as you can get quick verification of tests in surefire but also get validation of the final jar in failsafe.

I also see the notes that injection doesn't work in @QuarkusIntegrationTest. I can understand why this is the case but the guides seem to be lacking detail and examples. Is it expected to manually create test collaborators? If so how does one get access to the configuration to do so? For example, if starting up on a random port - how do I get the port?

In my specific case I am testing a grpc service. I have a @QuarkusTest with a @GrpcClient (as per the guides) to exercise the service. I've (maybe naively) attempted to extend this class with @QuarkusIntegrationTest (also as per the guides). The result is that the injected grpc client is null. What is the recommended approach for this case - is it documented anywhere?

I've looked though the Quarkus grpc integration tests and they seem to side-step the problem. The grpc services also have a rest service wrapping them, so the @GrpcClient is inside the application container. The tests merely exercise the rest endpoint.

Many thanks for any pointers here.

[quarkus-bot[bot]]

/cc @geoand (testing)

[geoand]

This seems sensible as you can get quick verification of tests in surefire but also get validation of the final jar in failsafe

True, it's the easiest way to get started.

Is it expected to manually create test collaborators? If so how does one get access to the configuration to do so? For example, if starting up on a random port - how do I get the port?

You can get the port by doing: ConfigProvider.getConfig().getValue("quarkus.http.test-port", Integer.class);

As for the @GrpcClient thing you mention, that won't work because the test is not part of the application (intentionally).
@cescoffier maybe we need to provide something to make it easier to exercise these services from integration tests?

[nahguam]

You can get the port by doing: ConfigProvider.getConfig().getValue("quarkus.http.test-port", Integer.class);

Gotcha, thanks.

As for the @GrpcClient thing you mention, that won't work because the test is not part of the application (intentionally).
@cescoffier maybe we need to provide something to make it easier to exercise these services from integration tests?

Yes, understood. It would be great to have something like a test-scope DI so that the dev experience is the same whether you're writing @QuarkusTest or @QuarkusIntegrationTest. But then that's more magic to grok as well if (and when) things go unexpectedly.

What I've settled on for now is a common test base class:

abstract class ExampleServiceImplTestBase {
    abstract Channel channel();

    @Test
    void test() {
        ExampleServiceBlockingStub client = ExampleServiceGrpc.newBlockingStub(channel());
        /// ...
    }
}

unit test:

@QuarkusTest
public class ExampleServiceImplTest extends ExampleServiceImplTestBase {
    @GrpcClient("client") Channel channel;

    @Override
    Channel channel() {
        return channel;
    }
}

intergration test:

@QuarkusIntegrationTest
class ExampleServiceImplIT extends ExampleServiceImplTestBase {
    private static ManagedChannel channel;

    @BeforeAll
    static void beforeAll() {
        int port = ConfigProvider.getConfig().getValue("quarkus.http.test-port", Integer.class);
        channel = ManagedChannelBuilder.forAddress("localhost", port)
                .usePlaintext()
                .build();
    }

    @AfterAll
    static void afterAll() {
        if (channel != null) {
            channel.shutdownNow();
            channel = null;
        }
    }

    @Override
    Channel channel() {
        return channel;
    }
}

and props:

%test.quarkus.grpc.server.in-process.enabled=true
%test.quarkus.grpc.clients.client.in-process.enabled=true
%prod.quarkus.grpc.server.use-separate-server=false
quarkus.http.test-port=0

So now I have unit-tests running in-process and integration tests running on random-ports 👍