Provide CDI Context in QuarkusIntegrationTests

[Marco Bungart]

I would like to start a little discussion on the following topic.

As of now, we have two specialized testing annotations: @QuarkusTest and
@QuarkusIntegrationTest. When we use @QuarkusTest, we gain the
capability to use the CDI context of the system under test which - in
turn - allows us to mainipulate this context (e.g. by injecting mocks).

@QuarkusIntegrationTests, on the other hand, are designed to be black
box test. Therefore, we cannot manipulate the system under test. This -
so far - is clear. It would be beneficial, however, if we had a CDI
context for the @QuarkusIntegrationTests, not to manipulate the system
under test (as I said - black box testing, the system should not be
modified), but fur the tests themselfs. Currently, there are no core
features using any CDI context, but there might be in the future.

With quarkus-cucumber, we already have a quakiverse extension that would
benefit massively by having a CDI context. For an example, transporting
information from one cucumber-step to another is normally done through a
CDI-bean. A minimal version of such a test can be found here[1].

Now the question: what's your stand on the above? Do you think that
providing a CDI context in @QuarkusIntegratoinTests is a useful feature?
Is it too niche? Should we provide a separate annotation for "black-box
testing with CDI context"?

Opinions welcome :)


[1]: https://bitbucket.org/turing85/quarkus-cucumber/src/master/

[Georgios Andrianakis]

Hi Marco,

Thanks for sharing your thoughts on this.

I totally understand where you are coming from with this - in a lot of cases it makes developers lives easier to have certain things configured in the test automatically so the test can then access the environment of the application (not the application itself) in order to either set things up or perform assertions.

Doing things however with CDI for black box tests could potentially incur significant complexity (as Quarkus would need to figure out only what the test needs and not attempt to setup code that starts any sort of server or tries to contact downstream services) while also giving users the illusion that the black box test can do similar things as the regular test.

So I would like to know what exactly your test code is doing? Does it set up CDI beans that it then expects to be usable throughout the tests? Are there any touch points between these test beans and the application code?

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/77042afe-e263-9039-c199-9de0d669f28e%40googlemail.com.

[Marco Bungart]

Hi!

The class holding the cucumber-steps [1] injects a separate bean called actor (defined in [2]) to share information between cucumber-steps (for example: read something form one step, pass it along to another step so it is used in some verification).

[1]: https://bitbucket.org/turing85/quarkus-cucumber/src/master/src/test/java/de/turing85/quarkus/cucumber/integration/steps/HttpSteps.java

[2]: https://bitbucket.org/turing85/quarkus-cucumber/src/master/src/test/java/de/turing85/quarkus/cucumber/integration/actors/HttpActor.java

[Georgios Andrianakis]

So in your case you want CDI only in order to support writing tests? There is no interaction with application code?

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/326bd2d5-c691-4d85-aff3-4641cc8b87b9n%40googlegroups.com.

[Marco Bungart]

Correct. Accessing information of "production code beans" would be a "nice to have" (e.g. to pull the path from endpoint classes).

@Georgios sorry for sending the mail twice, forgot to click "reply all" on the 1st mail.

[Stuart Douglas]

I don't think that we should do this. IMHO it would be very confusing, as when running QuarkusTest you would have a CDI context that is shared with the application, and when running QuarkusIntegrationTest you have a different manually setup CDI environment that isn't.

I guess we could look at an alternate way of doing lifecycle management for objects in tests, but I don't know how generally useful that would be.

Stuart

[Georgios Andrianakis]

On Tue, Dec 7, 2021 at 1:54 AM Stuart Douglas <sdou...@redhat.com> wrote:

I don't think that we should do this. IMHO it would be very confusing, as when running QuarkusTest you would have a CDI context that is shared with the application, and when running QuarkusIntegrationTest you have a different manually setup CDI environment that isn't.

+10

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cwi7bHU0CEzK3VEGbQ-eO0YzdPUxMLm4o4RTTV96R7i6A%40mail.gmail.com.

[Ladislav Thon]

Frankly, I don't think there's anything preventing you from manually booting a CDI container in `@QuarkusIntegrationTest` e.g. using Weld. While I agree it would be confusing to have a shared CDI container in `@QuarkusTest` and two different disconnected CDI containers in `@QuarkusIntegrationTest`, I think that's because we've historically shown that `@QuarkusIntegrationTest` is often an empty subclass of `@QuarkusTest`, which is confusing^2 (especially considering that `@QuarkusTest` is actually a an integration test as well, if you care about terminology). We should  disentangle them first.

út 7. 12. 2021 v 8:27 odesílatel Georgios Andrianakis <gand...@redhat.com> napsal:

I guess we could look at an alternate way of doing lifecycle management for objects in tests, but I don't know how generally useful that would be.

I guess I can't see why we would ever want to build a second CDI :-)

(Which is what Arquillian did. When writing Arquillian tests, I still accidentally use Arquillian's `@ApplicationScoped` from time to time. Ugh!)

LT

 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-m-1XspVXsSRoCmChBSHCeW79zf4Og%2BwrRgCoefH3T_gQ%40mail.gmail.com.

[Marco Bungart]

Do we have a tutorial on how to start a CDI container? And where/how would we start it?

The one thing that would be really nice to have is access to the properties defined in the config sources.

My current workaround is to let the tests run as @QuarkusTest, which allows me to use ArC. Downside is, however, that it boots up the whole application. Depending on how the application is structured, this may lead to situations where the test deployment needs access to 3rd party systems in order to boot properly, which I'd like to avoid.

[Roland Lichti]

Hi,

I don't see why it is more confusing to have two separate CDI context when using QuarkusIntegrationTest and a shared CDI context in QuarkusTest vs. having no CDI context in QuarkusIntegrationTest and a shared CDI context in QuarkusTest. It's confusing in both situations and needs documentation.

It could be confusing to _change_ the behaviour but since ther eis no CDI context yet available in the tests in QuarkusIntegrationTest it should not affect too many people. While having a CDI context for the tests separated from the workload CDI context could be very helpful in writing tests.

Mit freundlichen Grüßen / Kind Regards,

Roland Thomas Lichti, JBCD

He/Him/His

Principal Consultant

Red Hat Deutschland GmbH

Werner-von-Siemens-Ring 14

85630 Grasbrunn

rli...@redhat.com    
M: +49-172-6328604    

__________________________________________________________________________

Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, 
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cwi7bHU0CEzK3VEGbQ-eO0YzdPUxMLm4o4RTTV96R7i6A%40mail.gmail.com.