Gradle Plugin - Introduce integration test source set

[edeandrea]

This came from #21997 and #23488.

#21997 moves the maven-failsafe-plugin configuration out of the native profile and into the main profile.

#23488 changes the way codestarts generate sample code - specifically removing @NativeImageTest in favor of @QuarkusIntegrationTest.

When generating a Gradle project, the project contains a native-test source set. This name no longer aligns with the notion of integration test.

This issue is for the creation of a new source set representing integration tests (call it int-test, intTest, integration-test, or whatever else you'd like to call it).

This would all have to be backwards compatible of course, for a period of time. Projects already out there that have the native-test source set should still work, and any customizations to it should "flow" into this new source set.

It would have a rippling effect as well, since the Gradle plugin also has the testNative task, along with the nativeTestImplementation and nativeTestRuntimeOnly configurations.

To be consistent we'd have to introduce a new source set (something like int-test). We'd have to figure out a proper hierarchy (is the new source set the parent or child of the existing native-test source set?) and then apply configuration to it.

The new source set would most likely have to become the child of the existing one, so that any tweaks any current users have made will automagically "flow" into this new source set.

Then we'd have to update the documentation. And do we also introduce a new task testIntegration to be consistent? Now we have the same backwards compatibility problem there as well. We'd need to maintain backwards compatibility for a period of time.

The direction that is decided as part of #21997 (whether to always run integration test or have the user opt-into it - this comment) may dictate this behavior (i.e. keep it consistent). Personally I would think that it should all be tied back into the build task, so running ./gradlew build would run the unit tests, build the application (native, container image, jar, etc), and then execute the integration tests against whatever is built.

Originally posted by @edeandrea in #21997 (comment)

[quarkus-bot]

/cc @glefloch, @quarkusio/devtools

[glefloch]

As mentionned in #23528, and looking at the plugin code, we indeed have a testNative task that depends on quarkusBuild. When running the testNative task we force the quarkus.package.type property to native, meaning that running ./gradlew clean testNative will first trigger a quarkusBuild with the system property quarkus.package.type=native.

When first running ./gradlew quarkusBuild and then ./gradlew nativeTest, @QuarkusIntegrationTest tests work because gradle won't run the quarkusBuild as it looks "UP-TO-DATE" (which is an issue with the task input/output I think)

Thus it not possible to run @QuarkusIntegrationTest in one command.

As you mentionned @edeandrea introducing a new intTest source set with the same configuration as the native-test source set (without setting the quarkus.package.type property) will allow to run @QuarkusIntegrationTest tests.

In the future, we should deprecate the native-test source set in favor of the intTest source set.

Also, the naming between both source set differs, there shouldn't live together, as the user should migrate from native-test to intTest.

[glefloch]

BTW the check and build goal are not linked to the gradle plugin. We could link them to the plugin too.

[edeandrea]

Sounds good. For integration tests though I'm not sure it makes sense to link to the check task since the integration tests require the fully built binary (output of quarkusBuild).

You could make the new intTest task be triggered by the build task (by build.finalizedBy(tasks.intTest)). We should probably wait on the direction decided in #21997 though. I'm sure @gsmet would have the same concerns here as well.