4.x: Ability to Inject MockBeans in Helidon #7694

[jbescos]

Description

#7694

Documentation

This feature provides a simple mechanism for replacing CDI bean with mock instances created with Mockito.
It is similar to Spring's @MockBean, in fact it uses the same name.

The introduced API consist of a new Maven module io.helidon.microprofile.testing:helidon-microprofile-testing-mocking that provides one annotation @MockBean.

The annotation is designed to be used on fields of test classes annotated with @HelidonTest, the implementation relies only on CDI thus it works with either JUnit or TestNG.

The annotation has a parameter "answer" that can be used to set the default answer for the mocked beans.

See a snippet below:

@HelidonTest
@AddBean(TestMockBeanAnswer.Resource.class)
@AddBean(TestMockBeanAnswer.Service.class)
class TestMockBeanAnswer {

    @MockBean(answer = Answers.CALLS_REAL_METHODS)
    private Service service;
    @Inject
    private WebTarget target;

    @Test
    void injectionTest() {
        String response = target.path("/test").request().get(String.class);
        assertThat(response, is("Not Mocked"));
        Mockito.when(service.test()).thenReturn("Mocked");
        response = target.path("/test").request().get(String.class);
        assertThat(response, is("Mocked"));
    }

    @Path("/test")
    public static class Resource {

        @Inject
        private Service service;

        @GET
        public String test() {
            return service.test();
        }
    }

    static class Service {

        String test() {
            return "Not Mocked";
        }

    }
}

The mocked beans of a test class can be customized with a CDI producer method.
E.g.

@Produces
MockSettings mockSettings() {
    return Mockito.withSettings().defaultAnswer(Answers.RETURNS_DEFAULTS);
}

[jbescos]

Setting it as a draft for now. I have a couple of CDI questions:

Question 1:

Currently @MockTest requires also @Inject:

    @Inject
    @MockBean
    private Service service;

Is there any way to not require @Inject?.

Question 2:

It does not work if the bean already exists in CDI. For example, this will not work because the service will be defined twice (you need to remove @AddBean(Service.class)):

@HelidonTest
@AddBean(Service.class)
public class TestMockBean {

    @Inject
    @MockBean
    private Service service;

I didn't find how to replace the existing bean defined by the mocked one.

[romain-grecourt]

I didn't find how to replace the existing bean defined by the mocked one.

I'm not a CDI expert, but can you set the mocked bean as an alternative ? That's how the current solution (#8339) works.

[jbescos]

I didn't find how to replace the existing bean defined by the mocked one.

I'm not a CDI expert, but can you set the mocked bean as an alternative ? That's how the current solution (#8339) works.

I think that requires a producer, and I cannot use a producer because you need to know the type in advance. I will try it further. Do you know who is expert on this?, I bet for @tomas-langer

[jbescos]

Question 1 is answered in this commit: 57ac20b

[jbescos]

Question 2 solved here: e0cd11b
You were right @romain-grecourt with the alternatives, thanks.

[jbescos]

For TestNG it seems we cannot use the @Inject in constructor, so the @MockBean applies only in fields.

For example, this simple test:

@HelidonTest
class TestMockBeanField {

    private final WebTarget target;

    @Inject
    public TestMockBeanField(WebTarget target) {
        this.target = target;
    }

    @Test
    void test() {
    }
}

It fails with:

org.testng.TestNGException: 
An error occurred while instantiating class io.helidon.microprofile.tests.testing.testng.TestMockBeanField. Check to make sure it can be instantiated/accessed.
	at org.testng.internal.objects.SimpleObjectDispenser.createInstance(SimpleObjectDispenser.java:113)
	at org.testng.internal.objects.SimpleObjectDispenser.dispense(SimpleObjectDispenser.java:40)
	at org.testng.internal.objects.GuiceBasedObjectDispenser.dispense(GuiceBasedObjectDispenser.java:28)
	at org.testng.internal.ClassImpl.getDefaultInstance(ClassImpl.java:106)
	at org.testng.internal.ClassImpl.getInstances(ClassImpl.java:136)
	at org.testng.TestClass.getInstances(TestClass.java:129)
	at org.testng.TestClass.initTestClassesAndInstances(TestClass.java:109)
	at org.testng.TestClass.init(TestClass.java:101)
	at org.testng.TestClass.<init>(TestClass.java:66)
	at org.testng.TestRunner.initMethods(TestRunner.java:483)
	at org.testng.TestRunner.init(TestRunner.java:356)
	at org.testng.TestRunner.init(TestRunner.java:309)
	at org.testng.TestRunner.<init>(TestRunner.java:184)
	at org.testng.SuiteRunner$DefaultTestRunnerFactory.newTestRunner(SuiteRunner.java:652)
	at org.testng.SuiteRunner.init(SuiteRunner.java:224)
	at org.testng.SuiteRunner.<init>(SuiteRunner.java:116)
	at org.testng.TestNG.createSuiteRunner(TestNG.java:1375)
	at org.testng.TestNG.createSuiteRunners(TestNG.java:1349)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1191)
	at org.testng.TestNG.runSuites(TestNG.java:1114)
	at org.testng.TestNG.run(TestNG.java:1082)
	at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:155)
	at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeSingleClass(TestNGDirectoryTestSuite.java:102)
	at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:91)
	at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:137)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
	at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
	at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)

[romain-grecourt]

Looks nice so far.
We need to update the docs as well.

[tomas-langer]

This looks like a great feature, but the hard dependency on mockito is something we probably do not desire.
It seems to me that the whole feature is implemented as a CDI extension. Can we maybe create a new module (depending on mockito), that would add the CDI extension and the annotation, and that could be used with both JUnit5 and testNG extension, because it is "just" a CDI portable extension?
i.e. helidon-microprofile-testing-mock-beans?

[tomas-langer]

A few small things.

[tomas-langer]

Looks good now, let's wait for library approval.

[barchetta]

Dependencies look good to me. Thanks for all the work on this!

[romain-grecourt]

Looks good, please update the PR description to fill-in the documentation section:

• describe the feature (what it solves)
• describe the API (annotation + new GAV)
• add sample snippet

Let's also file an issue to create the actual docs for this feature.

needs documentation

[jbescos]

Looks good, please update the PR description to fill-in the documentation section:

* describe the feature (what it solves)

* describe the API (annotation + new GAV)

* add sample snippet

Let's also file an issue to create the actual docs for this feature.

Do we re-use this issue?: #8339

I didn't work in any documentation issue before, is there any guide?

[romain-grecourt]

Do we re-use this issue?: #8339

Let's file a separate issue as #8339 has more to it than strictly document this new feature.
If we want to proceed with #8338 we have to figure out where it fits in the docs.

I didn't work in any documentation issue before, is there any guide?

No, however adding one more document is relatively easy as there is a lot of precedence.

---

The bullet items I provided was guidance not a template. It should read like a short documentation of the feature not like a form !

[jbescos]

This is the new issue:
#8772

Are there more changes required in this PR or can it be approved/merged. I guess the documentation changes will be submitted in the new issue I created.

[romain-grecourt]

LGTM, nice work.
I've updated the description.