Add beans created using @MockBean as singletons rather than via a bean definition
#6664
Comments
wilkinsona
added
the
for: team-attention
|
I think registering as a singleton would mean that we need a different fix for #6602 |
|
Other than #6602, this approach looks quite fruitful. Here's a prototype that addresses numerous |
snicoll
added
type: enhancement
snicoll
pushed a commit
that referenced
this issue
Sep 2, 2016
Post-processing of mocked beans causes a number of problems: - The mock may be proxied for asynchronous processing which can cause problems when configuring expectations on a mock (gh-6573) - The mock may be proxied so that its return values can be cached or so that its methods can be transactional. This causes problems with verification of the expected calls to a mock (gh-6573, gh-5837) - If the mock is created from a class that uses field injection, the container will attempt to inject values into its fields. This causes problems if the mock is being created to avoid the use of one of those dependencies (gh-6663) - Proxying a mocked bean can lead to a JDK proxy being created (if proxyTargetClass=false) as the mock implements a Mockito interface. This can then cause injection failures as the types don’t match (gh-6405, gh-6665) All of these problems can be avoided if a mocked bean is not post-processed. Avoiding post-processing prevents proxies from being created and autowiring from being performed. This commit avoids post-processing by registering mocked beans as singletons as well as via a bean definition. The latter is still used by the context for type matching purposes. Closes gh-6573, gh-6663, gh-6664
|
Fixed in 0e00a49 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When registered via a bean definition the mock is subject to post-processing. This includes creation of proxies for caching and async processing. It also means that the container attempts to autowire the mock's fields (if it was created from a class rather than an interface). We could avoid this by adding the bean to the bean factory as a singleton.
The text was updated successfully, but these errors were encountered: