#32: Add capability to write QuarkusIntegrationTests

[turing85]

While at it, reformat and unify code.

Resolves #32

[turing85]

closed, superfluous.

[turing85]

Premature closure. It is not superfluous after all

[stuartwdouglas]

Why is this using Weld? Quarkus uses ArC as its CDI implementation?

If I am reading this right you want to be able to basically do injection on the client side outside the packaged application?

Is this really necessary? A normal @QuarkusIntegrationTest does not support injection on the test side, and I think adding a new injection provider into the mix could really confuse things.

[stuartwdouglas]

@mkouba could we possibly leverage your new QuarkusComponentTest work to allow injection into the client side of integration tests? I am not sure how compelling the use case is but I know we don't want a weld dependency.

[turing85]

Why is this using Weld? Quarkus uses ArC as its CDI implementation?

If I am reading this right you want to be able to basically do injection on the client side outside the packaged application?

Is this really necessary? A normal @QuarkusIntegrationTest does not support injection on the test side, and I think adding a new injection provider into the mix could really confuse things.

@stuartwdouglas See https://groups.google.com/g/quarkus-dev/c/HGZhNw6jsLg/m/KWptjIg6CQAJ - This was the advice given by Ladislav at the time.

[turing85]

@mkouba could we possibly leverage your new QuarkusComponentTest work to allow injection into the client side of integration tests? I am not sure how compelling the use case is but I know we don't want a weld dependency.

I played around with QuarkusComponentTest and got it working. Only inconvenience is that there must be some configuration on each test class that lists all (entry-) beans. This basically boils down to listing all step-classes and would look something like so:

public class CucumberResourceIT extends CucumberQuarkusIntegrationTest {
    @RegisterExtension
    static final QuarkusComponentTestExtension COMPONENT_TEST_EXTENSION = new QuarkusComponentTestExtension(
        CucumberResourceSteps.class, CucumberResourceActor.class);

    public static void main(String... args) {
        runMain(CucumberResourceIT.class, args);
    }
}

Right now, all classes that we want to be (actually) injected must be listed in the extension configuration. Otherwise, an automatic mock will be created.

[turing85]

@stuartwdouglas @mkouba I have a POC based on @QuarkusComponentTest here (github.com). Usability is still improvable, and we'd need to wait for a release of quarkus containing component tests, but it is a first step. Care to take a look?

[mkouba]

I'm not so sure it's a good idea to mix the QuarkusComponentTestExtension with CucumberQuarkusIntegrationTest. I think that what Stuart meant was to reuse some logic from the QuarkusComponentTestExtension, i.e. init an ArC container for the classes you want to inject in the CucumberQuarkusIntegrationTest. Basically some logic from the QuarkusComponentTestExtension.initArcContainer() and QuarkusComponentTestExtension.afterAll() methods.

[vsevel]

we are interested in this as well. hoping this goes through at some point.