QuarkusIntegrationTest runs tests against a separately built Quarkus application artifact rather than an application running in the test JVM. The artifact may be an executable JAR, container, or native binary. The test communicates through exposed APIs, making this the required approach for testing native images and containers. section 2.2.2 section 5.2
A common structure keeps endpoint tests in a QuarkusTest class and adds an empty QuarkusIntegrationTest subclass. The subclass inherits the same tests, allowing them to run against both the JVM application and a packaged artifact when their behavior is compatible. section 2.2.2 section 5.2.1
Use the annotation with these constraints:
- Exercise the application through REST or another HTTP API instead of injecting CDI beans into the test. section 5.2.1
- Expect native-mode tests to require a separate Maven or Gradle build; continuous testing does not support them. section 5.2
- Do not rely on test-side mocking or CDI injection in native mode or separate-JVM JVM-mode integration tests. section 5.2
- Use DisabledOnIntegrationTest to exclude individual methods that are incompatible with a particular artifact type. section 5.2
Inherited endpoint test
A ReservationResourceTest uses RestAssured to create a reservation through the REST endpoint. ReservationResourceIT is an empty QuarkusIntegrationTest subclass, so the same HTTP test runs in native mode without CDI injection. section 5.2.1
Listing 2.6 Quarkus integration test
package org.acme;
import io.quarkus.test.junit.QuarkusIntegrationTest;
@QuarkusIntegrationTest
public class GreetingResourceIT extends GreetingResourceTest {
// Execute the same tests but in packaged mode.
}
Shows the minimal integration-test class: annotate a subclass with QuarkusIntegrationTest and inherit the reusable endpoint tests. section 2.2.2
