Profile-specific application.properties not found in src/test/resources

[knutwannheden]

Describe the bug

When @TestProfile is used to use a non-standard config profile, then the profile-specific file (like application-french.properties in the attached example) is only found if it resides in src/main/resources. not when in src/test/resources.

Example project to reproduce the issue: code-with-quarkus.zip

Expected behavior

It should be possible for a test to use a profile-specific config file, which is in the test folder src/test/resources. Currently this is not the case.

Actual behavior

It would appear that a Quarkus Test with an @TestProfile annotation only loads the profile-specific application.properties file from src/main/resources.

How to Reproduce?

Build the attached example using mvn verify and the test GreetingResourceTest (see below) will fail.

@QuarkusTest
@TestProfile(GreetingResourceTest.MyTestProfile.class)
public class GreetingResourceTest {

    @Test
    public void testHelloEndpoint() {
        given()
          .when().get("/hello")
          .then()
             .statusCode(200)
             .body(is("Bonjour from RESTEasy Reactive"));
    }

    public static class MyTestProfile implements QuarkusTestProfile {
        @Override
        public String getConfigProfile() {
            return "french";
        }
    }
}

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.8.0.Final

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[knutwannheden]

/cc @radcortez

[radcortez]

Ah, you are missing an application.properties file (it may even be empty) to make the resource discoverable. This is to keep a consistent loading order and match with the unprofiled resource.

The issue is that if we call ClassLoader#getResources on each individual file pattern, we end up with unordered files and we don't know how to set the priorities. I guess we could look into the entire path and try to match them, but we took an easier approach which is, we load only application.properties, and if that exists in we look for profile files in the same location. So the loading order is consistent and we know easily who overrides who.

What we do need is to clarify that in the documentation.

[knutwannheden]

Yes, I had indeed missed that. I thought that I would be able to have application.properties in main and application -test.properties in test.