The English version of is the official project site. Translated sites are community supported on a best-effort basis.

Quarkus now supports test profiles

With the release of Quarkus 1.6 Quarkus now supports test profiles, allowing you to easily test multiple different configurations inside the same module. This post outlines what test profiles are and how you can use them.

Recap on how @QuarkusTest works

Before we talk about test profiles let’s talk briefly about how @QuarkusTest annotated tests actually work. The first time one of these tests is run the Quarkus test extension will start Quarkus. Quarkus will then remain running for the duration of the test run. This makes testing very fast, because Quarkus is only started once, however it does limit you to testing a single configuration per module, as you can’t restart Quarkus in a different configuration. Test profiles lift this limitation.

Test profiles

Test profiles are defined by the io.quarkus.test.junit.QuarkusTestProfile interface. To define a profile you need to provide an implementation of this interface. This interface looks like the following:

 * Defines a 'test profile'. Tests run under a test profile
 * will have different configuration options to other tests.
public interface QuarkusTestProfile {

     * Returns additional config to be applied to the test. This
     * will override any existing config (including in,
     * however existing config will be merged with this (i.e.
     * config will still take effect, unless a specific config key has been overridden).
    default Map<String, String> getConfigOverrides() {
        return Collections.emptyMap();

     * Returns enabled alternatives.
     * This has the same effect as setting the 'quarkus.arc.selected-alternatives' config key,
     * however it may be more convenient.
    default Set<Class<?>> getEnabledAlternatives() {
        return Collections.emptySet();

     * Allows the default config profile to be overridden. This basically just sets the quarkus.test.profile system
     * property before the test is run.
    default String getConfigProfile() {
        return null;

Basically this interface allows you to do three different things:

  • Provide configuration overrides to run Quarkus with a different config. Note that these are overrides, so existing config will still be present, unless it has been explicitly overridden.

  • Specify some CDI @Alternatve beans that you want to enable for this profile. This allows you to replace beans in the application with test specific ones, essentially mocking them out.

  • Run with a different configuration profile, rather than the default test profile.

To actually use this profile we specify it using the @TestProfile annotation, as follows:

public class MyTestClass {

This test class will now be run with the settings specified in the MyProfile class.

How it works

Before a @QuarkusTest is executed the Quarkus test extension will check the profile that the test wants to use, and compares it to the profile that was used by the last test. If they are the same then no action is taken, the currently running Quarkus application is already using the correct profile. If they are different then Quarkus is stopped, and then started with the new config.

In general it is best to stop and start Quarkus as few times as possible for the fastest possible test runs. To do this it is recommended that you run your tests in alphabetical order, and configure all tests that require specific profiles into their own package. This means that all tests with the same profile will be run together, so Quarkus will be restarted a minimal number of times.


These profiles will have additional features added as time goes on (1.7 will include support for custom test resources per profile). If there is anything else you would like supported or have any other feedback please let us know.