This commit improves the user experience for common use cases by
introducing new `value` attributes in @MockitoBean and
@MockitoSpyBean that are aliases for the existing `name` attributes.
For example, this allows developers to declare
@MockitoBean("userService") instead of @MockitoBean(name =
"userService"), analogous to the existing name/value alias support in
@TestBean.
Closes gh-33680
Based on feedback from the Spring Boot team, we have decided to change
the default values for the enforceOverride flags in @TestBean and
@MockitoBean from true to false.
Closes gh-33613
This commit simplifies the field injection logic for Bean Overrides in
order to align with the semantics of the core container and the Spring
TestContext Framework.
Closes gh-33677
This change avoids the trap of creating a copy of `HttpHeaders` using a
case-sensitive `MultiValueMap` by mistake. Since mutability is always
desirable, we make a mutable copy by using `addAll` on an empty
`HttpHeaders`.
We can't simply rely on HttpHeaders' map-based constructor to detect
read-only header in this particular case, because the container's
original headers representation might in some cases be read-only.
Closes gh-33666
This set of commits introduces AOT and native image support for the new
Bean Override feature in the Spring TestContext Framework -- for
example, for using @TestBean and @MockitoBean in AOT mode on the JVM
as well as in a GraalVM native image.
Note, however, that @MockitoBean has currently only been tested in a
native image when mocking interfaces and using Mockito's
ProxyMockMaker, along with a custom runtime hints.
Closes gh-32933
Instead, MockitoResetTestExecutionListener is now only enabled if the
current test class uses Mockito annotations or Mockito-related
annotations in spring-test.
See gh-32933
This commit introduces a BeanOverrideReflectiveProcessor which
registers runtime hints for any BeanOverrideProcessor configured
via @BeanOverride.
See gh-32933
Prior to this commit, AOT processing failed for tests that made use of
the Bean Override feature to "override" a nonexistent bean. The reason
is that we register a "pseudo" bean definition as a placeholder for a
nonexistent bean, and our AOT support cannot automatically convert that
"pseudo" bean definition to a functional bean definition for use at AOT
runtime.
To address that, this commit skips registration of "pseudo" bean
definitions during AOT processing, and by doing so we enable the JVM
runtime and AOT runtime to operate with the same semantics.
See gh-32933
Prior to this commit, AOT processing failed for tests that made use of
the Bean Override feature, since the Set<OverrideMetadata> constructor
argument configured in the bean definition for the
BeanOverrideBeanFactoryPostProcessor cannot be properly processed by
our AOT support. The reason is that each OverrideMetadata instance is
effectively an arbitrary object graph that cannot be automatically
converted to a functional bean definition for use at AOT runtime.
To address that, this commit registers Bean Override infrastructure
beans as manual singletons instead of via bean definitions with the
infrastructure role.
See gh-32933
Sam Brannen
Stéphane Nicoll
Seungrae
Asi Bross
rstoyanchev
Simon Baslé
Juergen Hoeller
Johnny Lim
Brian Clozel
Dariusz Jędrzejczyk