TestProfile specific CDI beans

[ennishol]

Description

It would be beneficial if we could generate beans in custom test profiles. These beans would then take the place of the existing beans, but only for the current @QuarkusTest, as demonstrated below:

@QuarkusTest
@TestProfile(MyIT.Profile.class)
class MyIT {

    @Inject
    CustomBean custom;
    @Inject
    ExistingBean existing;


    @Test
    void aTest() throws Exception {
      //
    }

    static class CustomBean {
    }

    public static class Profile implements QuarkusTestProfile {
        
        @ApplicationScoped
        @Produces
        public CustomBean customBean() {
            //add new bean to context, exists only in MyIT
            return new CustomBean();
        }
        @ApplicationScoped
        @Produces
        public ExistingBean existingBean() {
            //replace existing bean in context only in MyIT
            return new ExistingBean();
        }
        
        @Override
        public Map<String, String> getConfigOverrides() {
            return Map.of("my.property", "false");
        }
    }
}

Implementation ideas

I believe something like that exists in spring

[quarkus-bot]

/cc @Ladicek (arc), @manovotn (arc), @mkouba (arc)

[Ladicek]

If I understand correctly, this should already be possible with @IfBuildProfile (https://quarkus.io/guides/cdi-reference#enable_build_profile). It's possible the QuarkusTestProfile has to set up a new config profile, when you want different beans for different profiles. Did you try that?

[mkouba]

If I understand correctly, this should already be possible with @IfBuildProfile (https://quarkus.io/guides/cdi-reference#enable_build_profile). It's possible the QuarkusTestProfile has to set up a new config profile, when you want different beans for different profiles. Did you try that?

Another option is to use QuarkusTestProfile#getEnabledAlternatives() and define those beans as disabled alternatives.

[ennishol]

Thanks for your help @Ladicek , @mkouba

I've tried @IfBuildProfile and adding a new bean is indeed not a problem. However, replacing an existing one is harder, as it requires me to mark the production bean with @DefaultBean. It would be nice if quarkus test would recognize that I want to replace it and auto-add @DefaultBean to my production bean.
Also I"m not always in control of beans, which might come from a library

[Ladicek]

The replacement could be an @Alternative I think? Then you wouldn't need to modify the original.

[ennishol]

@Ladicek tried @Alternative with QuarkusTestProfile#getEnabledAlternatives() but it didn't work. I've got an exception about 2 beans available.

[mkouba]

@Ladicek tried @Alternative with QuarkusTestProfile#getEnabledAlternatives() but it didn't work. I've got an exception about 2 beans available.

@ennishol This should work. Could you share your test code?

[ennishol]

@mkouba
production code

@ApplicationScoped
public class ProdService {
    public String hello() {
        return "production";
    }
}

@ApplicationScoped
public class OtherService {
    @Inject
    ProdService prodService;

    public String hi() {
        return prodService.hello();
    }
}

Test

@QuarkusTest
@TestProfile(MyIT.Profile.class)
class MyIT {


    /**
     * this bean exists only in this test
     */
    @Inject
    CustomBean customBean;

    /**
     * ProdService is injected in OtherService
     * and we want to replace ProdService with TestService
     * in this test only
     */
    @Inject
    OtherService otherService;

    @Test
    void aTest() {
        assertThat(customBean.hello()).contains("hi", "customprofile", "test", ",");
        assertThat(otherService.hi()).isEqualTo("testing");
    }

    static class CustomBean {
        String hello() {
            return "hi " + String.join(",", ConfigUtils.getProfiles());
        }
    }

    @IfBuildProfile("customprofile")
    static class TracingConfig {
        @ApplicationScoped
        CustomBean customBean() {
            return new CustomBean();
        }

        @ApplicationScoped
        ProdService testService() {
            return new TestService();
        }
    }

    @Alternative
    static class TestService extends ProdService {
        @Override
        public String hello() {
            return "testing";
        }
    }

    public static class Profile implements QuarkusTestProfile {

        @Override
        public String getConfigProfile() {
            return "test,customprofile";
        }

        @Override
        public Set<Class<?>> getEnabledAlternatives() {
            return Set.of(TestService.class);
        }

        @Override
        public Map<String, String> getConfigOverrides() {
            return Map.of("somproperty", "false");
        }
    }
}

[mkouba]

@ennishol Well, the ProdService bean is produced by the TracingConfig#testService() producer which is not an alternative and does not need to be enabled in the profile and there will be an ambiguous dependency because the ProdService is also a managed bean with @ApplicationScoped.

You should remove the TracingConfig#testService() producer and add a scope annotation to the TestService.

[ennishol]

@mkouba thanks! That works. It would be nice if it also worked from a producer method without the need to manually specify the alternative. Maybe quarkus could detect @Alternative beans in the test class and auto-add them? So that the user doesn't have to implement getEnabledAlternatives method?

[mkouba]

@mkouba thanks! That works. It would be nice if it also worked from a producer method without the need to manually specify the alternative. Maybe quarkus could detect @Alternative beans in the test class and auto-add them? So that the user doesn't have to implement getEnabledAlternatives method?

Hm, I kind of understand but the problem is that (1) it would break compatibility - right now, any bean declared in a static nested class of a test class is registered in all test profiles (including the default/implicit one), (2) you would need to use a custom test profile anyway. So I think that it's better to stick with an explicit declaration.

By the way, if you only need to test your CDI components then try out the QuarkusComponentTest instead.

Your test would look like (I've removed the CustomBean as it only asserts the test profiles):

@QuarkusComponentTest
@TestConfigProperty(key = "somproperty", value = "false")
class MyComponentTest {

    @Inject
    OtherService otherService;

    @Test
    void aTest() {
        assertThat(otherService.hi()).isEqualTo("testing");
    }

    @ApplicationScoped
    static class TestService extends ProdService {
        @Override
        public String hello() {
            return "testing";
        }
    }

}

[ennishol]

@mkouba Yes, @QuarkusComponentTest is great, but it is not the use case I have in mind.

I understand your points and it's kind of how CDI works. But from the testing perspective, a test is isolated from other tests. Why should any bean declared in test X be also registered for test Y? This global state will sooner or later cause trouble if the project is big enough.

If a global bean is needed for all tests I would define it then in a separate non-test class.

What if all beans and config are defined in the TestProfile? At least then it shouldn't break anything. If someone defines beans and alternatives in QuarkusTestProfile implementation then it is obvious that the beans would be valid only there

[Ladicek]

But from the testing perspective, a test is isolated from other tests.

That is by design not true for @QuarkusTest. All @QuarkusTest tests in the same profile share the same application, including the full set of beans (which includes beans declared in tests, because there's nothing special about static member classes of test classes).

I understand this is confusing and perhaps unexpected, at least for people who subscribe to the ordinary testing pyramid, but this is how it is. I assume @QuarkusTest makes much more sense for people who subscribe to the inverted tested pyramid, but I don't really know :-)

[mkouba]

But from the testing perspective, a test is isolated from other tests.

That is by design not true for @QuarkusTest. All @QuarkusTest tests in the same profile share the same application, including the full set of beans (which includes beans declared in tests, because there's nothing special about static member classes of test classes).

Exactly, unless a custom test profile is used. In that case, a new test application is started for all the tests that share the same test profile.

[ennishol]

"Exactly, unless a custom test profile is used. In that case, a new test application is started for all the tests that share the same test profile"

And that is my point. why should anything from this test influence any other test profiles

[mkouba]

"Exactly, unless a custom test profile is used. In that case, a new test application is started for all the tests that share the same test profile"

And that is my point. why should anything from this test influence any other test profiles

Well, you can use the class in other tests too. In theory, we could try to detect static nested classes declared on a class that is annotated with @TestProfile and then only consider the class if the test profile is used (I don't know if that's feasible though). But this would be still a breaking change...

[ennishol]

@mkouba that would be really cool!

[Ladicek]

I agree that would make sense. It seems fairly unlikely that anyone declares beans on a @TestProfile class, and if they do, it also seems fairly unlikely that they want such beans to be available in other test profiles.

[Ladicek]

Actually I forgot how test profiles and @TestProfile work. What I had in mind is beans declared as static member classes of the test profile implementation. That seems like a good place where one should declare beans that should only exist in the given profile.

When it comes to beans declared on test classes annotated @TestProfile... yeah, we could still prevent those from leaking to other profiles, but I generally think that with @QuarkusTest, one just shouldn't declare beans in test classes. The behavior is highly counter-intuitive.

[mkouba]

What I had in mind is beans declared as static member classes of the test profile implementation.

I like this idea. We'll see if I come with a pull request ;-).