Mock ApplicationScoped beans at Startup

[radcortez]

• Fixes mocked RestClient in startup bean - missing uri #51784

This eagerly creates mocks for ApplicationScoped beans, so if beans are used during Startup and the test marks them for mocking, Startup does not fail. This can be observed when injecting a REST Client in a Startup bean and calling any methods before the test executes. Currently, mocks are created only when the test executes, but Startup beans run before, causing the issue.

I've experimented with different approaches, and this one seemed to be the least intrusive, including generating Alternative beans, creating the mocks used by the test before execution, and some other variations.

The downside is that when you run the test, you get a different mock from the one used in the StartupBean. I've looked into making this global and reusing the same mock, but ultimately, I ditched the idea because it would cause issues with parallel testing.

To achieve this, I require a build item to register the bean candidates and then create the mock in our own high-priority Startup bean.

Still missing:

• Support for @InjectSpy
• Maybe clear the mocks after Startup?
• Maybe move junit-mockito to a full-fledged extension?

[radcortez]

@geoand before proceeding, I wanted to validate the approach

[geoand]

The downside is that when you run the test, you get a different mock from the one used in the StartupBean

But this means that you can't control the mock from the test, right?

[radcortez]

But this means that you can't control the mock from the test, right?

For code that executes during startup, no, because we don't have a way to retrieve that particular mock from the test, but other calls will work. Consider:

@Startup
@ApplicationScoped
public class StartupService {
    @Inject
    @RestClient
    GreetingRestClient greetingRestClient;

    @PostConstruct
    void onStart() {
        greetingRestClient.greeting();
    }

    public String greeting() {
        return greetingRestClient.greeting();
    }
}

The @PostConstruct onStart, executes with an empty mock, created eagerly, proposed by this PR, to not fail the startup. When calling greeting(), it will execute on the lazy mock created by the specific test.

Using @BeforeAll or other semantics doesn't work because Quarkus startup is an atomic operation when executing a test. We could introduce a hook to give you access to the startup mocks, so you can also control that particular mock. Between that, or using an @Alternative as proposed in #51830 (comment). It seems a more natural solution than introducing yet another construct for this specific case.

I think this is mostly a corner case that we can document and point to the @Alternative solution.

Do you have another idea?

[geoand]

I think this is mostly a corner case that we can document and point to the @Alternative solution.

Yeah, that sounds like the most reasonable thing to do

[radcortez]

Closing in favour of #52684