Support bean override features with AOT and native image

[sbrannen]

Overview

Although @MockitoBean and @MockitoSpyBean will not work out-of-the-box within a GraalVM native image due to their dependency on Mockito, the general Bean Override support for tests should ideally work within a native image.

In light of that, we need to ensure that basic usage of @TestBean is supported within a native image, and (if applicable) we will need to document known use cases that are not supported for some reason.

To achieve that, we need to introduce a smoke test application that makes use of @TestBean and verify the expected behavior when the associated tests are run within a native image against Spring Framework 6.2 snapshots or milestones.

We also have to ensure that the necessary runtime hints are registered for the bean override support. For example, we will need tests which verify that reflection hints are registered for the BeanOverrideContextCustomizerFactory, etc.

As a bare minimum, TestContextAotGeneratorIntegrationTests.endToEndTests() must be modified to include test classes that utilize the basic features of @TestBean.

Related Issues

• Help wanted: compiling mockito with native-image mockito/mockito#2435
• Support Mockito with @MockBean and @SpyBean in AOT-processed tests spring-boot#32195
• Verify AOT testing support for all tests in the spring-test module #29122
• @TestBean and @MockitoBean tests fail in AOT mode #32925
• Introduce dedicated AOT tests for bean override support in the TCF #32932

[snicoll]

I've requalified this issue to investigate how much of these features can be supported by AOT on the JVM and in a native image.

[sbrannen]

In order to get the ball rolling, I started experimenting with AOT/native support for test bean overrides.

Current experimental work on this issue can be viewed in the following feature branch.

• main...sbrannen:spring-framework:testbean-aot-support

There are several issues we will need to address, including, but not limited to, the following.

• Bean override infrastructure beans must be able to be handled by our AOT processing.
  • With the status quo, we face issues with the Set<OverrideMetadata> constructor argument configured in the bean definition for the BeanOverrideBeanFactoryPostProcessor.
• Beans created by OverrideMetadata implementations must be able to be handled by our AOT processing.
  • With the status quo, we face issues with the "dummy" bean definitions we create for @MockitoBean and @MockitoSpyBean beans.
• We currently register "dummy" bean definitions for overridden beans and simultaneously register instances of those beans as singletons; whereas, we should ideally just register proper bean definitions for those beans.

As a side note, we should keep in mind that a ContextCustomizer currently cannot be made "AOT aware", since that can potentially affect how we implement the feature regarding our use of bean definitions and manually registered singletons.

In the first commit on the aforementioned feature branch (sbrannen@b8f69eb), I switched to registering bean override infrastructure beans as singletons instead of via bean definitions with the infrastructure role. I'm not suggesting that's necessarily what we want to do in the end, but doing so allows our @TestBean and @DummyBean tests to work in AOT mode.

In the second commit in that feature branch (sbrannen@102ec94), I introduced a different approach to creating bean override instances which allows a concrete OverrideMetadata implementation to update the override BeanDefinition so that it is suitable for use in AOT -- for example, by registering a static factory method that is responsible for creating the bean instance. I verified this approach works for @TestBean and @DummyBean; however, getting this approach to work for @⁠MockitoBean or @⁠MockitoSpyBean will be significantly more involved.

In any case, we at least now have some topics that we can discuss.