Introduce @QuarkusIntegrationTest

[geoand]

The basic idea of this annotation is to test the final artifact produced by the Quarkus build, no matter what that is (a jar, a native binary or a container image).

TODO:

• Polish code
• Add tests
• Add documentation

Resolves: #13818

[geoand]

This will conflict with #14960, so I'll wait until that one is merged

[geoand]

I have now added tests and cleaned things up a little.

@stuartwdouglas mind taking a look and letting me know what you think?

[ebramirez]

Hi @geoand, could this be extended to include testing quarkus-picocli applications?

[geoand]

I am not sure, I haven't really worked with the picocli extension.

What do you expect testing of a picocli application would look like?

[ebramirez]

I imagine that given a Picocli command like this:

@Command
public class MyCommand {
    @Parameters( paramLabel = "PARAM", description = "App parameter", arity = "1" )
    Path param;

    @Option( names = { "--option", "-o" }, required = true )
    String option;

	/* Setters and Getters */
}

We could test it like this:

@QuarkusIntegrationTest
class MyCommandTest {

    @Inject
    MyCommand myCommand;

    @Test
    void testValidOptions() {
        myCommand.setPath( "/my/path/param.txt" );
		myCommand.setOption( "my option" );

        final int exitStatus = myCommand.execute();

        assertThat( exitStatus ).isEqualTo( 0 );
    }
}

The execute() method from the injected command would pick up the annotated Options and Parameters and pass them to the appropriate launcher.

[geoand]

That can't work with this type of testing as the test launches a separate process and thus cannot interact with the application in any way other than standard ways to interact with a separate process - which is just a fancy way of say that @Inject can't work in these tests

[ebramirez]

Sorry for not explaining myself properly: the injected Command would not be the real command, just a proxy to collect the Options and Properties and pass them to the appropriate launcher (Jar, Native, Docker...).

Maybe something similar, but more automated, to using @InjectMock and @RestClient.

Does this make sense.

[geoand]

Thanks for the explanation.

That is probably possible and I'll consider it in the future.

[stuartwdouglas]

Its probably a massive corner case that we don't care about, but this won't display properly if you have a muti byte character that falls on the 100 byte mark.

[geoand]

Sounds like a corner case indeed 🙂.
But I'll keep it in mind and deal with it if it ever becomes a problem.

[stuartwdouglas]

This is ok for now, but I think long term we want the extension that contributes the artifact to also provide the launcher somehow to make this extensible.

[geoand]

Definitely. I was thinking of having a Service loader.
Once that need arises, I'll change the code ASAP

[geoand]

I'm gonna keep this PR in draft until we get DevDB support in as they will conflict and the DevDB support is more high value

[geoand]

At last the Windows tests on my fork as passing

[pipinet]

#15198

[geoand]

Fixed conflict

[geoand]

GH seems to have messed up this PR.

I'll try to reopen later on or else just open a new one

[geoand]

Superseded by #15227