adam bien's blog

quarkus.io is the perfect System Test driver. Quarkus watches the changes and continuously rebuilds and re-executes the tests for you.

The tests can be maintained in a dedicated maven project with minimal dependencies:

<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-arc</artifactId>
</dependency>
<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-junit5</artifactId>
    <scope>test</scope>
</dependency>

In this configuration, quarkus won't open any HTTP ports and will work as a test driver only. In this screencast I used JDK 11 HttpClient to test the mockend utility:

import io.quarkus.test.junit.QuarkusTest;
import java.io.IOException;
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse.BodyHandlers;
import javax.inject.Inject;
import org.eclipse.microprofile.config.inject.ConfigProperty;
import org.junit.jupiter.api.Test;

@QuarkusTest
public class GreetingResourceTest {

    @Inject
    @ConfigProperty(name = "service.uri")
    URI uri;

    @Test
    public void testHelloEndpoint() throws IOException, InterruptedException {
        var client = HttpClient.newHttpClient();
        var request = HttpRequest.newBuilder(uri).GET().headers("Accept", "application/json").build();
        var response = client.send(request, BodyHandlers.ofString());
        var body = response.body();
        //...
    }
}

Maintaining the tests in an isolated module comes with the following benefits:

1. There is no cheating: you will have to explicitly declare all dependencies
2. Given you are using a production client implementation like e.g. JAX-RS client, MP REST client, or Java 11 HttpClient, the System Test becomes (re)usable as a microservice client.
3. The API's backward compatibility is verifiable by checking out an older version of the system test module and executing them against the current version of the service
4. The System Test module can be used by other projects in their CI / CD pipeline to verify the compatibility from their point of view
5. The system test module clearly demonstrates how to call the API and therefore becomes an additional documentation
6. The system tests are directly reusable as Smoke / Stress Tests
7. It is a true blackbox test