Support Bean Overrides (such as `@MockitoBean`) on test constructor parameters

[sdeleuze]

Like there is a parameter resolver for @Autowired, it would be useful to have one for @MockBean, especially in Kotlin where it would enable using val instead of lateinit var.

cc @sbrannen

[sbrannen]

I can imagine Boot users requesting similar support for other Boot testing features such as @LocalServerPort, so the team might want to review all DI annotations and consider whether it makes sense to support them via a ParameterResolver for JUnit Jupiter.

[sbrannen]

Oh wait... I just realized that @LocalServerPort is simply meta-annotated with @Value("${local.server.port}").

So there's nothing special to do there: the SpringExtension already supports parameter resolution for @Value. 😉

[sbrannen]

@sdeleuze, the challenge with supporting @MockBean and @SpyBean via a JUnit Jupiter ParameterResolver is that org.springframework.boot.test.mock.mockito.DefinitionsParser would have to be revised to search for those annotations on parameters instead of the status quo (i.e., only on classes or fields).

The question is what Boot would ultimately want to support for those annotations.

Since the Spring TestContext Framework currently does not support loading of an ApplicationContext on a per-method basis, I imagine that Boot would want to limit support for declaring @MockBean and @SpyBean on parameters to test class constructors.

In other words, I don't think it would make much sense to support those annotations on parameters for test methods or test lifecycle methods.

[sdeleuze]

Indeed my use case is only for constructor parameters.

@ExtendWith(SpringExtension::class)
@WebMvcTest
class HttpApiTests(@Autowired val mockMvc: MockMvc) {

	@MockBean
	private lateinit var userRepository: UserRepository

	@Test
	fun foo() { }
}

Versus

@ExtendWith(SpringExtension::class)
@WebMvcTest
class HttpApiTests(@Autowired val mockMvc: MockMvc,
                   @MockBean val userRepository: UserRepository) {

	@Test
	fun foo() { }
}

[philwebb]

Since the Spring TestContext Framework currently does not support loading of an ApplicationContext on a per-method basis, I imagine that Boot would want to limit support for declaring @MockBean and @SpyBean on parameters to test class constructors.

Yeah, we'd need to limit this because mocks == new context.

[krzyk]

@sdeleuze Is there any plan to support per-method ApplicationContext?
Isolating all test cases sounds like a quite desirable thing.

[davinkevin]

I do a small up on this one, due to the date of the last message.

[wilkinsona]

Please use the 👍 and 👎 reactions on the issue description to indicate your interest rather than spamming the issue with comments.

[xenoterracide]

Please use the 👍 and 👎 reactions on the issue description to indicate your interest rather than spamming the issue with comments.

does that actually work? because I totally came here to report this 4 years later

[xenoterracide]

It would seem currently that the only option is to write a second test class since I only wanted to mock this for one test method.

[wilkinsona]

Given the plan to deprecate @MockBean in Spring Boot 3.4 and the introduction of @MockitoBean in Spring Framework 6.2, I don't think we should do anything here. A parameter resolver for @MockitoBean could be added to Spring Framework if there's still demand for this.