1.7.0.CR1: TestProfile + TestResource doesn't work in Native tests

[juangon]

Describe the bug
As I wanted to separate native and "normal" tests, I made two TestProfiles, each of them have a custom TestResource with a MariaDB container (using testcontainers) on them. Each MariaDB has their own schema name etc (I changed it as I've seen native tests are using the same schema and container as normal tests) .

First issue came when I tried to set jdbc parameters for native tests in their own TestResource, it doesn't work.
Second issue, when setting them manually in "application.properties", it doesn't connect.

So, it looks like TestResources doesn't work on native tests. MariaDB container for native tests isn't used or started.

Expected behavior

Custom parameters set in TestResource for native tests are applied.
Custom TestResource for native tests are started and used.

Actual behavior

Neither parameters nor container is started in native tests.

To Reproduce
Steps to reproduce the behavior:

1. Unzip attached reproducer
   quarkus_issue.zip

2. Execute ./mvnw clean verify -Dnative

3. Look native tests failing as it can't connect to native test resource, which is a testcontainer's Maria DB.

Configuration

# DATASOURCE
quarkus.datasource.db-kind = mariadb
quarkus.datasource.username = normal
quarkus.datasource.password = normal
quarkus.datasource.jdbc.url = jdbc:mysql://localhost/normal

%test.quarkus.hibernate-orm.database.generation=drop-and-create
%test.quarkus.hibernate-orm.sql-load-script =import_test.sql

%nativetest.quarkus.datasource.username = nativetest
%nativetest.quarkus.datasource.password = nativetest
%nativetest.quarkus.hibernate-orm.database.generation=drop-and-create
%nativetest.quarkus.hibernate-orm.sql-load-script =import_test.sql


quarkus.native.additional-build-args =\
-H:ResourceConfigurationFiles=resources-config.json


quarkus.test.native-image-profile=nativetest

Screenshots
(If applicable, add screenshots to help explain your problem.)

Environment (please complete the following information):

• Output of uname -a or ver: 5.4.0-42-generic
• Output of java -version: openjdk version "11.0.8" 2020-07-14
• GraalVM version (if different from Java):
• Quarkus version or git rev: 1.7.0.CR1
• Build tool (ie. output of mvnw --version or gradlew --version): Apache Maven 3.6.3

Additional context
I changed profile for generated native build, as I didn't want it to be default "prod".

[geoand]

Thanks for reporting this.

Actually the @NativeImageTest doesn't support @TestProfile at all (the reason being that it takes a long time to build a native binary and definitely don't want to do that multiple times for a test run).

I have opened #11150 to explicitly prevent this usage.

[juangon]

Thanks @geoand , then what's the strategy to test native builds with other needed components? Reuse the non native tests resources?

[geoand]

Due to the long time it takes to build a native image, all native image tests must work with the same components.

So the general idea is that if you need to have differentiated tests, those will only be for the JVM mode (i.e @QuarkusTest) - the native image tests will only test a final (think "production") application.

[juangon]

Ok but, what I asked is what could I use to start some containers to test native builds against. I thought about @QuarkusTestResource but as what I know those are always started only when they exists...

[geoand]

I understand the question, and the answer is the same 😉.

You'll have to start up all components you need in a @TestResource (which is of course supported for @NativeImageTest) and use those components throughout your native image testing.

If you need to differentiate the components, the you can only do that with @QuarkusTest + @TestProfile

[juangon]

Ok thanks again. Last question, is true that everyting implementing QuarkusTestResourceLifecycleManager is started no matter if it's annotated within @QuarkusTestResource?

[juangon]

And it looks weird, as having multiple QuarkusTestResourceLifecycleManager they can mix with other ones, even if they aren't specified in the test's @QuarkusTestResource . If some properties are changed in start()method, they can be applied to other test!

[geoand]

Ok thanks again. Last question, is true that everyting implementing QuarkusTestResourceLifecycleManager is started no matter if it's annotated within @QuarkusTestResource?

No, that is not true.

A class that implements QuarkusTestResourceLifecycleManager will only be used if

• It's annotated with @QuarkusTestResource (in which case it's used for all profiles)
• It's used in QuarkusTestProfile#testResources (in which case it's used only for the @TestProfile that uses said QuarkusTestProfile)

[gsmet]

@geoand is this issue specific to 1.7.0.CR1 and considered a regression? It doesn't feel like it?

[geoand]

It's a 1.6 issue, but with the advent of specific QuarkusTestResourceLifecycleManager for test profiles, it's easier for users to run into this now.

I suggest we do backport it because otherwise users end up in a situation where things seemingly should work, but they don't and there is absolutely no indication what's going on.

[juangon]

Ok thanks very much. Unfortunately this issue #10225 still exist. I can't make native test working and populating DB using properties quarkus.hibernate-orm.sql-load-scriptetc. Can someone take a look?

[juangon]

@geoand the funny thing about #10225 is that I should specify prodprofile for these properties to work. It sounds weird and I think isn't an expected behavior.
Thanks!

[geoand]

You are welcome

[famod]

Ok thanks very much. Unfortunately this issue #10225 still exist. I can't make native test working and populating DB using properties quarkus.hibernate-orm.sql-load-scriptetc. Can someone take a look?

I did and unfortunately I had to close that issue (with a proper reasoning, of course).
Short story: Those dreaded hibernate build time properties again...

[geoand]

Ah, a classic 🙃

[juangon]

@famod thanks very much for the info and that hibernate link.