-
Notifications
You must be signed in to change notification settings - Fork 41.2k
MockBean does not resolve the right type for abstract test class #20916
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This might be happening because the mock is created for the @onacit Just to be sure, could you provide a minimal sample that we can run to reproduce the issue? |
@mbhave Thank you. I managed to create a simplest and reproducible project from my original code base. https://github.com/onacit/spring-boot-issue20916 There is only one
|
Thanks for the sample @onacit. I have taken a look and it seems like a bug to me. It is marked |
The fix for gh-20916 updated DefinitionsParser so that the ResolvableType for each MockBean or SpyBean field included the implementation class from which the field was found. Where the field was declared with a variable generic signature that was made constant by its implementation class, this allowed the correct concrete type to be determined. It also had the unintended side-effect of preventing two test classes with identical `@MockBean` and `@SpyBean` configuration from sharing a context as the resolvable types for their mock and spy bean fields would now be different. This commit updates DefinitionsParser to only include the implementation class in the ResolvableType if the field's generic type is variable. For cases where it is not variable, this restores the behaviour prior to the fix for gh-20916. Fixes gh-22566
Could this be backported to 2.2.x ? |
@Xyaren The fix was made in 2.2.9. |
I'm sorry, picket I got confused between two issues. Thanks for the quick response! |
Uh oh!
There was an error while loading. Please reload this page.
Please forgive me if this kind of issue is not appropriate. I already SO-ed.
Just in cases of issue titles, this issue might have a same issue with #15969. I'm not sure.
I have a tightly coupled abstract service class with generic types.
I have an abstract service class which autowires a specific type of repository.
Now I'm trying to create an abstract test class for subclasses of the service class.
But mocking the bean in a test class of actual service class works.
(Which is I intended that extended modules don't have to do.)
Is there any intrinsic mechanism for mocking the
SomeServiceTest#serviceIntance.repositoryInstance
?The text was updated successfully, but these errors were encountered: