Quarkus Dev Services et Tests
Vérifiez d'abord la version de Quarkus du projet. L'utilisation de Testcontainers indépendante du framework peut utiliser la skill optionnelle java-testcontainers si installée (sinon voir https://java.testcontainers.org/); cette skill couvre uniquement les fonctionnalités spécifiques à Quarkus.
Dev Services
En modes dev et test, Quarkus démarre automatiquement des conteneurs (PostgreSQL, MySQL, Kafka, Redis, Keycloak, ...) quand l'extension correspondante est présente et qu'aucune connexion n'est configurée (Docker ou Podman requis).
# Commutateur global
quarkus.devservices.enabled=true
%dev.quarkus.datasource.devservices.image-name=postgres:17
# Réutiliser le conteneur entre les redémarrages (nécessite aussi testcontainers.reuse.enable=true dans ~/.testcontainers.properties)
quarkus.datasource.devservices.reuse=true
# Port fixe (optionnel)
quarkus.datasource.devservices.port=5432
# Partager entre les apps en mode dev
quarkus.kafka.devservices.shared=true
Désactivez-en un avec quarkus.<ext>.devservices.enabled=false; configurer explicitement une URL/host le désactive aussi. Le Dev UI (/q/dev-ui) liste les services en cours d'exécution.
Tests
@QuarkusTest
class GreetingResourceTest {
@Test
void hello() {
given().when().get("/hello").then().statusCode(200).body(is("Hello"));
}
}
Dépendances, scope test : io.quarkus:quarkus-junit (3.31+, ce que génère le template 3.40) ou quarkus-junit5 (template 3.27; toujours publié et résolvable sur 3.40) et io.rest-assured:rest-assured. Conservez celui que le projet utilise déjà.
- Injectez des beans dans les tests avec
@Inject; mockez les beans CDI avecio.quarkus.test.InjectMock(quarkus-junit-mockito, anciennementquarkus-junit5-mockito; mockage d'un beanPanacheRepositoryvérifié sur 3.40.1). - Sécurité :
@TestSecurity(user="alice", roles="admin")(quarkus-test-security). - Profils :
@TestProfile(MyProfile.class)avecQuarkusTestProfile#getConfigOverrides(); redémarre l'app, à utiliser avec parcimonie. - Transactions :
@TestTransactionrevient en arrière après le test. @QuarkusIntegrationTests'exécute contre l'artefact packagé (jar, binaire natif ou conteneur); vous ne pouvez pas injecter de beans là, seulement l'appeler via HTTP.
Ressources de test
public class WireMockResource implements QuarkusTestResourceLifecycleManager {
public Map<String,String> start() { /* démarrer, retourner les overrides de config */ return Map.of(); }
public void stop() { }
}
@QuarkusTest
@WithTestResource(WireMockResource.class) // io.quarkus.test.common.WithTestResource
class MyTest { }
@WithTestResource (vérifié sur 3.40.1) s'applique à la classe de test annotée; Quarkus redémarre l'app quand l'ensemble des ressources change. L'ancienne @QuarkusTestResource compile et s'exécute toujours sur 3.40.1 mais s'applique globalement à tous les tests à moins que restrictToAnnotatedClass = true. Ne mettez pas de points d'injection @ConfigProperty pour les valeurs fournies par la ressource dans une classe de test : les classes de test sont scannées en tant que beans, et l'app ne démarre pas pour les autres classes de test qui n'ont pas la ressource. Préférez Dev Services aux ressources personnalisées quand une extension les supporte.
Exécution
./mvnw test # unit/@QuarkusTest
./mvnw verify -DskipITs=false # exécute aussi *IT via maven-failsafe-plugin
Piège : les classes *IT (@QuarkusIntegrationTest) sont exécutées par Failsafe dans la phase verify, et nécessitent le goal build du quarkus-maven-plugin et la config failsafe (avec les propriétés système java.util.logging.manager et maven.home) générés par le template du projet. ./mvnw test les ignore silencieusement, et les templates 3.27 et 3.40 définissent aussi <skipITs>true</skipITs>, donc le simple ./mvnw verify les ignore aussi (vérifié) : passez -DskipITs=false (ou -Dnative, dont le profil l'active). Avec -Dnative et une build conteneurisée sur macOS ou Windows, le binaire est un ELF Linux et l'IT échoue avec Exit code is: '126'; utilisez une build Mandrel/GraalVM locale pour ceux-ci.
Tests continus : exécutez ./mvnw quarkus:dev et appuyez sur r pour démarrer ou réexécuter les tests et p pour les mettre en pause (h liste les raccourcis); une fois en cours, les tests se réexécutent lors des changements de code (quarkus.test.continuous-testing=enabled|paused|disabled).
Vérifié sur Quarkus 3.40.1 (JDK 26, Docker Desktop) : @QuarkusTest avec Dev Services PostgreSQL (postgres:18 par défaut), @TestTransaction, @TestProfile, @TestSecurity, @InjectMock, *IT via Failsafe. @QuarkusTest et Dev Services aussi sur 3.27.6.
Checklist
- Utilisez Dev Services avant d'écrire une ressource personnalisée.
- Gardez les classes
@QuarkusTestpartageant le même profil/ressources pour éviter les redémarrages. - Ne hard-codez pas les ports; RestAssured utilise
quarkus.http.test-portautomatiquement.
Voir aussi : https://quarkus.io/guides/dev-services, https://quarkus.io/guides/getting-started-testing; pour les mises à jour utilisez quarkus update (https://quarkus.io/guides/update-quarkus).