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

Comment From: 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.

Comment From: 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. πŸ˜‰

Comment From: 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.

Comment From: 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() { }
}

Comment From: 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.

Comment From: krzyk

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

Comment From: davinkevin

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

Comment From: wilkinsona

Please use the πŸ‘ and πŸ‘Ž reactions on the issue description to indicate your interest rather than spamming the issue with comments.

Comment From: 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

Comment From: 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.

Comment From: 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.

Comment From: xenoterracide

@wilkinsona do you guys have the ability to move tickets between spring projects? I know that GitHub added that ability a while back. Would it be possible simply to move (And reopen ) this issue over to the spring framework instead of having to have someone rewrite the whole thing?

Comment From: wilkinsona

I don't, but some of the team do as they're commiters projects.

@bclozel can please transfer this if appropriate or would the Framework team prefer a fresh issue?