Dev Services suppressed by test profile service properties

Documented Boundary for Dev Services Suppression

There is no single cross-extension property list that universally gates Dev Services. Each Quarkus extension defines its own quarkus.<extension>.devservices.enabled flag and decides which configuration properties signal an externally managed service. The common pattern across datasource, messaging, and cache extensions is: if a connection URL, host/port, or credential pair is resolved, the extension treats the service as externally configured and skips container startup.

For the built-in datasource (Agroal/Hibernate ORM), the suppressing properties include:

• quarkus.datasource.jdbc.url
• quarkus.datasource.username + quarkus.datasource.password
• quarkus.datasource.devservices.enabled=false (explicit opt-out)

Other extensions follow the same convention under their own prefix (e.g., quarkus.kafka.devservices.enabled, quarkus.redis.devservices.enabled). The reference guide for each extension documents its specific gating properties; there is no consolidated matrix.

Balancing Automatic Dev Services vs Explicit Test Containers

Recommended approach for teams that must keep production secrets out of src/test/resources:

1. Default to Dev Services in src/test/resources/application.properties — set quarkus.datasource.devservices.enabled=true (and equivalents for other extensions) and omit any URL/credential properties.
2. Use @TestProfile only for additive overrides — e.g., a profile that sets quarkus.datasource.db-kind=postgresql to select the Dev Services image, not to provide a JDBC URL.
3. For CI reproducibility, pin container images via Dev Services configuration (quarkus.datasource.devservices.image-name=postgres:16-alpine) rather than switching to Testcontainers manual lifecycle.
4. If an explicit Testcontainers instance is required (e.g., custom init scripts), define it in a @QuarkusTestResource and also set quarkus.datasource.devservices.enabled=false in the same test profile to avoid double startup.

Verification That Test Profile Has Not Disabled Container Startup

Run the following checks in the test execution environment (local or CI):

1. Observe Dev Services startup logs — run mvn quarkus:test -Dtest=YourTest and confirm lines like Starting Dev Services for PostgreSQL appear before test execution.
2. Resolve effective configuration — execute mvn quarkus:config -Dquarkus.profile=test (or ./mvnw quarkus:config with the active test profile) and verify:
   • quarkus.datasource.devservices.enabled = true
   • No quarkus.datasource.jdbc.url, username, or password are resolved.
3. Check ambient environment — ensure DATABASE_URL, JDBC_URL, or extension-specific env vars (e.g., KAFKA_BOOTSTRAP_SERVERS) are not set in the shell/CI job, as they bypass profile configuration and suppress containers.

Missing Diagnostic Detail

Which Quarkus version and which extensions (datasource, Kafka, Redis, etc.) are in use? The exact gating properties and log phrasing differ between 2.x and 3.x, and some third-party extensions may not honor devservices.enabled at all.