Quarkus testing framework

Quarkus provides a JUnit 5–based testing framework that starts an application instance for tests and tears it down afterward. Annotate a test class with @QuarkusTest to start the application and make Quarkus-managed facilities available. A test can inspect an injected CDI bean directly or exercise the application through an HTTP endpoint. section 5.1 section 5.1.1

Choose the test boundary to match what you need to verify:

• For a repository test, inject the repository into an @QuarkusTest class, save an object, and assert the resulting state. This tests an application bean directly. section 5.1.1
• For an endpoint test, send an HTTP request and check its status and response. Quarkus integrates with REST Assured so the test need not specify the server URL manually; @TestHTTPEndpoint and @TestHTTPResource can also inject an endpoint URL. section 2.2.2 section 5.2.1
• For tests needing different configuration or supporting services, use testing profiles or a QuarkusTestResourceLifecycleManager. Mockito integration and bean overrides are also available. section 5.1

package org.acme;

import io.quarkus.test.junit.QuarkusTest;
import org.junit.jupiter.api.Test;

import static io.restassured.RestAssured.given;
import static org.hamcrest.CoreMatchers.is;

@QuarkusTest
public class GreetingResourceTest {

    @Test
    public void testHelloEndpoint() {
        given()
          .when().get("/hello")
          .then()
             .statusCode(200)                      #1
             .body(is("Hello from Quarkus REST"));    #2
    }
}

The small @QuarkusTest example shows a JUnit 5 method calling /hello with REST Assured and asserting both HTTP 200 and the response body. section 2.2.2

Run JVM tests with ./mvnw test or enable continuous testing in Dev mode by pressing r. Continuous testing reruns tests after reloads in an isolated application instance. If the Dev mode application and test instance compete for the same HTTP port, set quarkus.http.test-port to another port—or to 0 for a free port. section 5.1.1 section 3.5

Use @QuarkusIntegrationTest to run against a packaged JAR, container, or native binary rather than the application in the test JVM. An integration-test class can extend an @QuarkusTest class to reuse HTTP-based tests. Because the test and application run in separate processes, CDI injection into the test and mocking are unavailable there; an injected-repository test cannot simply be reused for native testing. Native tests also require a separate build, not continuous testing. section 5.2 section 5.2.1

The framework also supports tests beyond straightforward HTTP calls. A RabbitMQ test can act as a reactive-messaging consumer, use Awaitility to wait for an asynchronous invoice, and select test-only messaging configuration with the %test prefix. For a custom extension, QuarkusUnitTest can boot an empty application with the extension loaded, allowing REST Assured to verify its endpoint without a separate application project. section 9.7.1 section 12.4