While working on #32933, I noticed some potential issues regarding singleton and scope semantics in our Bean Override support in spring-test, and I verified those assumptions in commit 9c746905bc38cc78aafc3f4b816e60663b8faca1.

  • If a FactoryBean signals it does not manage a singleton, the Bean Override support silently replaces it with a singleton.

  • An attempt to override a prototype-scoped bean or a bean configured with a custom scope results in one of the following.

  • If the bean type of the original bean definition is a concrete class, an attempt will be made to invoke the default constructor which will either succeed with undesirable results or fail with an exception if the bean type does not have a default constructor.
  • If the bean type of the original bean definition is an interface or a FactoryBean that claims to create a bean of a certain interface type, an attempt will be made to instantiate the interface which will always fail with a BeanCreationException.

In light of the above, we should rework the logic in BeanOverrideBeanFactoryPostProcessor.registerReplaceDefinition() so that only singleton beans can be overridden.

Comment From: jason-wilmans

Okay, stupid question: What do I do when I encounter this check and the bean I'm trying to mock with @MockitoBean (and is not a singleton) is outside of my control?