Restructure testing strategy to remove need for extra flag on build#23
Conversation
66fc0d0 to
d22c642
Compare
edeandrea
left a comment
There was a problem hiding this comment.
LGTM - can you also do the same on the other quarkus project so that they are the same?
Will do. I wondered about doing it and then wasn't sure if its testing should mirror the spring-y testing or the Quarkus testing. But I guess it can't fully mirror spring so it should go all in on Quarkus. |
Until the spring testing working group completes :) Then it should mirror spring :) |
6364252 to
0a6f002
Compare
Done! I had to make an adaptation to the application because by default the import.sql is always being loaded, even in prod mode. I also spotted that quarkusio/quarkus#40037 means we do not need to rename the data.sql file to import.sql on the spring project, so I renamed that file to reduce the diff to spring. |
To make it work, do not auto-load sql in prod mode for spring-compat apps
0a6f002 to
1e20f14
Compare
We would like it so that
mvn verifyworks out of the box on the Quarkus project. The reason it doesn't is because theQuarkusIntegrationTestruns in prod mode (as all integration tests do), and it assumes the database has been populated. We can move its tests to aQuarkusTest, which runs in test mode and so gets a populated database. Then, because of course we still want theQuarkusIntegrationTestcoverage, we can make aQuarkusIntegrationTestwhich assumes the database is empty on startup.This setup is hard to replicate in the Spring projects, and it means the Quarkus projects have more test coverage. I think this is ok, since we want the Quarkus project to be equivalent, but also idiomatic.