(Mis)using Quarkus as the perfect Black Box Test Driver

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

Comments:

Hi Adam,

i've tried what you have done in your video, but no test was executed.

I've download the mocked project and launch the executable jar created from 'mvn package'.

I've created a sample quarkus project, deleted the java folder, removed not used dependencies, and then created the test for the mocked endpoint.
Then i've launched the new project with 'mvn compile quarkus:dev' but no test was executed.

Do you have any suggestion?

Thanks

Posted by Aldo Lushkja on June 29, 2021 at 09:41 PM CEST #

Thanks Adam to you reply on 88th Airhacks TV to this question, migrating to Quarkus 2+ version solved the issue.
Only this little change was maded to pom.xml:

<quarkus.platform.version>2.0.1.Final</quarkus.platform.version>

Bye

Posted by Aldo Lushkja on July 08, 2021 at 12:11 AM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
Online Workshops
...the last 150 posts
...the last 10 comments
License