Repository navigation
@MockitoBean should allow a custom answer #34956
Description
Currently, there is no way to request a few mocks, provide answers (to share common setups), and automatically inject these mocks where needed.
@MockitoBean should have a property called answer, of type Class<? extends Answer>, and use the class (create an instance) when a mock is created in MockitoBeanOverrideHandler.createMock.
Activity
sbrannen commentedon May 28, 2025
Hi @adrian-tarau,
We don't consider it very common to configure a custom
Answerwith Mockito, and the documentation for Mockito also states something along those lines.However, we do support the standard
Answersenum from Mockito.Are you familiar with
@MockitoBean( answers = ... )?If
Answersdoes not meet your needs, what is it exactly that you are trying achieve when you say "to share common setups"?adrian-tarau commentedon May 29, 2025
@sbrannen I think Mockito says something like "in rare cases, etc., etc." :) However, it does not mean it is not needed or part of the API.
@MockitoBean( answers = ... )only provides default behaviours (also using an Answer). And by the way, RETURNS_SMART_NULLS should be used instead of RETURNS_DEFAULTS as a default value, as it allows for safer behavior (my 2 cents).The purpose of using custom answers is to provide shared behaviours (just like Mockito does internally) across repositories and services. I do not want to keep repeating the same pattern across tests within modules. For example:
The service is created, mocks are injected, and since ServiceA implements InitializingBean, the repositories will be called before behaviors can be added. If I could attach behaviours in the annotation, the mock would be done using a common behaviour.
I can provide a patch if the enhancement is approved/accepted. There are just a few lines of code, and while it may not be helpful or useful for everyone, it might be beneficial in some cases.
adrian-tarau commentedon May 29, 2025
@sbrannen, since the default answer in Mockito can be changed, please disregard RETURNS_SMART_NULLS vs RETURNS_DEFAULTS. Smart nulls are/should always be more useful.
adrian-tarau commentedon May 30, 2025
Forgot to mention: I know I can use @ TestBean and take over the creation of the mocked bean, but it's too much boilerplate code. Ultimately, the method I will use creates a mock of the bean (in this case, the repository) with a shared answer. It would be much better to provide an answer class with @MockitoBean.
bclozel commentedon Oct 23, 2026
Thanks for raising this, and sorry it has gone so long without a decision.
We're reviewing older issues to keep the tracker focused on work we can realistically plan. This request hasn't drawn much interest from the community and doesn't fit the current priorities, so we're declining it.
If it still matters to you on a current Spring Framework version, please add a comment with your use case and we can reconsider. A reproducer or concrete examples help a lot.