This commit introduces a test which verifies that @MockitoSpyBean on a
field with generics can be used to replace an existing bean with
matching generics that's produced by a FactoryBean that's
programmatically registered via an ImportBeanDefinitionRegistrar.
However, the test is currently @Disabled until the fix for
https://github.com/spring-projects/spring-boot/issues/40234 has been
ported to Spring Framework.
See gh-33742
In gh-33602, we introduced strict singleton enforcement for bean
overrides -- for example, for @MockitoBean, @TestBean, etc. However,
the use of BeanFactory#isSingleton(beanName) can result in a
BeanCreationException for certain beans, such as a Spring Data JPA
FactoryBean for a JpaRepository.
In light of that, this commit relaxes the singleton enforcement in
BeanOverrideBeanFactoryPostProcessor by only checking the result of
BeanDefinition#isSingleton() for existing bean definitions.
This commit also updates the Javadoc and reference documentation to
reflect the status quo.
See gh-33602
Closes gh-33800
This commit removes the proxyTargetAware attribute from @MockitoSpyBean
while keeping the underlying feature in tact (i.e., transparent
verification for spies created via @MockitoSpyBean).
Closes gh-33775
Prior to this commit, SpringAopBypassingVerificationStartedListener
provided partial support for transparent verification for Mockito spies
created via @MockitoSpyBean when the spy is wrapped in a Spring AOP
proxy. However, attempting to actually verify invocations for a spy
resulted in an exception from Mockito since MockUtil.isMock() returned
false in such scenarios.
This commit addresses that by introducing a SpringMockResolver that
resolves mocks by walking the Spring AOP proxy chain until the target
or a non-static proxy is found.
SpringMockResolver is automatically registered whenever the spring-test
JAR is on the classpath, allowing Mockito to transparently resolve mocks
wrapped in Spring AOP proxies.
Closes gh-33774
Prior to this commit, OverrideMetadata was the only public type in the
org.springframework.test.context.bean.override package whose name did
not start with BeanOverride. In addition, an OverrideMetadata component
plays multiple roles in addition to serving as a holder for metadata.
This commit therefore renames OverrideMetadata to BeanOverrideHandler.
In addition, this commit updates the affected documentation and renames
the following related methods in the Bean Override support.
- BeanOverrideHandler: createOverride() -> createOverrideInstance()
- BeanOverrideHandler: track() -> trackOverrideInstance()
- BeanOverrideProcessor: createMetadata() -> createHandler()
- BeanOverrideContextCustomizer: getMetadata() -> getBeanOverrideHandlers()
- BeanOverrideRegistrar: registerNameForMetadata() -> registerBeanOverrideHandler()
- BeanOverrideRegistrar: markWrapEarly() -> registerWrappingBeanOverrideHandler()
Closes gh-33702
This change remove the support for Mockito annotations, `MockitoSession`
and opening/closing of mocks that was inherited from Boot's `@MockBean`
support, as well as the switch to `MockitoSession` made in 1c893e6.
Attempting to take responsability for things Mockito's own JUnit
Jupiter extension does better is not ideal, and we found it leads to
several corner cases which make `SpringExtension` and `MockitoExtension`
incompatible in the current approach.
Instead, this change refocuses our Mockito bean overriding support
exclusively on aspects specific to the Framework. `MockitoExtension`
will thus be usable in conjunction with `SpringExtension` if one needs
to use `@Captor`/`@InitMocks`/`@Mock`/`@Spy` or other Mockito utilities.
See gh-33318
Closes gh-33692
Prior to this commit, the MockitoResetTestExecutionListener failed to
reset mocks created via @MockitoBean if the @MockitoBean field was
declared in an enclosing class for a @Nested test class. In addition,
the MockitoSession was not properly managed by the
MockitoTestExecutionListener.
This commit addresses those issue as follows.
1) The hasMockitoAnnotations() utility method has been overhauled so
that it finds Mockito annotations not only on the current test class
and on fields of the current test class but also on interfaces,
superclasses, and enclosing classes for @Nested test classes as well
as on fields of superclasses and enclosing classes.
That allows the MockitoResetTestExecutionListener to properly detect
that it needs to reset mocks for fields declared in enclosing classes
for @Nested classes.
2) MockitoTestExecutionListener has been revised so that it only
initializes a MockitoSession before each test method and closes the
MockitoSession after each test method. In addition, it now only manages
the MockitoSession when hasMockitoAnnotations() returns true for the
current test class (which may be a @Nested test class). Furthermore,
it no longer attempts to initialize a MockitoSession during the
prepareTestInstance() callback since that results in an
UnfinishedMockingSessionException for a @Nested test class due to the
fact that a MockitoSession was already created for the current thread
for the enclosing test class.
Closes gh-33676
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
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, ApplicationContext caching support was broken if
two Bean Override fields declared the same annotations but in a
different order.
This commit fixes that by switching to Set semantics for the
annotations declared on a Bean Override field.
Closes gh-33633
Prior to this commit, BeanOverrideBeanFactoryPostProcessor replaced
existing bean definitions with "pseudo" bean definitions; however, that
is unnecessary. An existing BeanDefinition is suitable as-is and does
not need to be replaced with a pseudo/fake definition.
To address that, this commit reregisters an existing bean definition
and only registers a new bean definition when creating a bean
definition for a nonexistent bean.
As a side effect, we no longer need to copy primary and fallback flags.
Closes gh-33627
Prior to this commit, @MockitoBean could be used to either create or
replace a bean definition, but @TestBean could only be used to replace
a bean definition.
However, Bean Override implementations should require the presence of
an existing bean definition by default (i.e. literally "override" by
default), while giving the user the option to have a new bean
definition created if desired.
To address that, this commit introduces a new `enforceOverride`
attribute in @TestBean and @MockitoBean that defaults to true but
allows the user to decide if it's OK to create a bean for a nonexistent
bean definition.
Closes gh-33613
Prior to this commit, a non-singleton FactoryBean was silently replaced
by a singleton bean. In addition, bean definitions for prototype-scoped
and custom-scoped beans were replaced by singleton bean definitions
that were incapable of creating the desired bean instance. For example,
if the bean type of the original bean definition was a concrete class,
an attempt was made to invoke the default constructor which either
succeeded with undesirable results or failed with an exception if the
bean type did not have a default constructor. If the bean type of the
original bean definition was an interface or a FactoryBean that claimed
to create a bean of a certain interface type, an attempt was made to
instantiate the interface which always failed with a
BeanCreationException.
To address the aforementioned issues, this commit reworks the logic in
BeanOverrideBeanFactoryPostProcessor so that an exception is thrown
whenever an attempt is made to override a non-singleton bean.
Closes gh-33602
The tests introduced in this commit reveal the following issues in our
Bean Override support.
- If a FactoryBean signals it does not manage a singleton, the Bean
Override support silently replaces it with a singleton.
- An attempt to override a prototype-scoped bean or a bean configured
with a custom scope results in one of the following.
- If the bean type of the original bean definition is a concrete
class, an attempt will be made to invoke the default constructor
which will either succeed with undesirable results or fail with an
exception if the bean type does not have a default constructor.
- If the bean type of the original bean definition is an interface or
a FactoryBean that claims to create a bean of a certain interface
type, an attempt will be made to instantiate the interface which
will always fail with a BeanCreationException.
Sam Brannen
Simon Baslé
Juergen Hoeller
Yanming Zhou