-
Notifications
You must be signed in to change notification settings - Fork 38.3k
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
@MockitoBean
incorrectly injects supertype into subtype field
#34025
Comments
Sorry it's bit synthetic but here is consistently failing version package com.example;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.springframework.test.context.bean.override.mockito.MockitoBean;
import org.springframework.test.context.junit.jupiter.SpringExtension;
@ExtendWith(SpringExtension.class)
class MockitoBeanTest {
@MockitoBean
private Foo1 foo1;
@MockitoBean
private Bar1 bar1;
@MockitoBean
private Foo2 foo2;
@MockitoBean
private Bar2 bar2;
@MockitoBean
private Foo3 foo3;
@MockitoBean
private Bar3 bar3;
@Test
void test() {
}
interface Foo1 {
}
interface Bar1 extends Foo1 {
}
interface Foo2 {
}
interface Bar2 extends Foo2 {
}
interface Foo3 {
}
interface Bar3 extends Foo3 {
}
} For what it's worth I think it depends on Lines 96 to 100 in da75840
beanOverrideHandlers is HashSet acually created here and passed down to BeanOverrideBeanFactoryPostProcessor .
If it happens so that handler for Additionally, if we set unique |
@MockitoBean
incorrectly injects supertype into subtype field
Thanks for bringing this to our attention, @nstdio. 👍 This indeed turns out to be an interesting one, and I've had some "debugging fun" in order to get to the bottom of it.
Yes, it depends on the order in which the handlers/fields are processed. It turns out this this bug exists with For example, the following @ExtendWith(SpringExtension.class)
class MockBeanTest {
@MockBean
Subtype subtype;
@MockBean
Supertype supertype;
@Test
void test() {
}
interface Supertype {}
interface Subtype extends Supertype {}
}
Yep, and it also succeeds if you apply Thus, when it fails it's because mocks are created "by type" without an explicit name or qualifier, and if a mock for a subtype is created first (e.g., |
This has been fixed in
And I decided to call that the "Phantom Read problem for Bean Overrides in the TestContext framework". 🤣 See aa7b459 for details. |
Interesting problem when using
@MockitoBean
with Spring Boot3.4.0
. Here's the test case to reproduce it. Please run it couple of times because it sometimes does work.Sometimes test case fails with following exception:
The text was updated successfully, but these errors were encountered: