Quarkus: Http Root Path is not gathered by NativeImageTest

Created on 30 Jul 2020  路  6Comments  路  Source: quarkusio/quarkus

Describe the bug
I'm create a CRUD application that is using Postgresql as database. And for tests:

  • I'm using testcontainers to be iso equal the runtime db.
  • I'm using, obviously, Rest Assured to verify that my REST APIs are returning the expected results
  • I'm inheriting every @QuarkusTest annotated class to an @NativeImageTest class, to be able to run my test on the native image.

In the @QuarkusTest classes everything is working perfectly.

Expected behavior
I expect that running the tests using : ./mvnw clean verify -Pnative but it's failing.

Actual behavior
The Rest Assured is giving status code 404 while the expected is 200..

I made a test that has a tread sleep, so I can check what is running inside the tested runtime.. I found my APIs available on the expected URLs and nothing is wrong.. I even get the data from the testcontainer db created for the tests using the QuarkusTestResource..

UPDATE: As I have the quarkus.http.root-path=/api configured. I duplicated the tests, while point on /customers in @QuarkusTest and /api/customers in @NativeImageTest, all the tests are passing successfully.

Even if I add %prod.quarkus.http.root-path=/api, the prefix never got discovered by the @NativeImageTest 馃槶

To Reproduce
Steps to reproduce the behavior:

  1. create crud app
  2. create test that verifies crud operations + testcontainer created DB using QuarkusTestResource
  3. inheriting @QuarkusTest annotated classes to an @NativeImageTest classes
  4. run ./mvnw clean verify -Pnative

Configuration

Main application.properties:

# Datasource config properties
quarkus.datasource.db-kind=postgresql
quarkus.datasource.username=developer
quarkus.datasource.password=p4SSW0rd
quarkus.datasource.jdbc.url=jdbc:postgresql://localhost:5432/demo
# Flyway minimal config properties
quarkus.flyway.migrate-at-start=true
# HTTP config properties
quarkus.http.root-path=/api
# Swagger UI
quarkus.swagger-ui.always-include=true

Tests application.properties:

# Datasource config properties
quarkus.datasource.db-kind=postgresql
# Flyway minimal config properties
quarkus.flyway.migrate-at-start=true

Environment (please complete the following information):

  • Output of uname -a or ver: 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
  • Output of java -version: OpenJDK 64-Bit Server VM GraalVM CE 20.1.0 (build 11.0.7+10-jvmci-20.1-b02, mixed mode, sharing)
  • GraalVM version (if different from Java):
  • Quarkus version or git rev: 1.6.1.Final
  • Build tool (ie. output of mvnw --version or gradlew --version): 3.6.3
kinbug triaginvalid

Most helpful comment

Yeah, it's best to have a single one.

Let's close this for now, but feel free to reopen or open another more focused issue about the test properties issue.

All 6 comments

It's really hard to try and figure out what's going on without a reproducer project - do you perhaps have one that demonstrates this issue?

Thank you @geoand for your fast respone 馃槉

I couldn't reproduce with a minimal project: here is the source of the Proof-of-concept that is having the issue.

Just fyi, the spring-data-jpa dependency is the one on master, as I'm depending on the fixes that will be shipped in the 1.7.0..

I've made a workaround, is to add the /api prefix to the rest assured paths when the test is executed under the prod profile 馃樂

I found the origin of this issue @geoand .. it happens when there is two application.properties, the main one and a second one in the test resources.

I moved back the test properties to the main application.properties with the %test profile prefix and deleted the second one and everything is working perfectly now..

Is it still to be an issue ? or it's mandatory/recommended to have only one application.properties file ?

Yeah, it's best to have a single one.

Let's close this for now, but feel free to reopen or open another more focused issue about the test properties issue.

Okey ! Thank you @geoand ! 馃槂

Thanks for reporting

Was this page helpful?
0 / 5 - 0 ratings