Skip to content

Bean override with REPLACE_OR_CREATE_DEFINITION and byType lookup fails if no match is found #32990

Closed
@snicoll

Description

@snicoll

Consider the following scenario:

@SpringJunitConfig
public class MyTest {

  @MockitoBean
  private ExampleService service;

}

With zero ExampleService in the context. MockitoBean has a REPLACE_OR_CREATE_DEFINITION strategy, which means it should create a (mock) bean for that type if none is found.

Right now it fails as:

Caused by: java.lang.IllegalStateException: Unable to select a bean definition to override: found 0 bean definitions of type org.springframework.test.context.bean.override.example.ExampleService (as required by annotated field 'ZeroCandidatesTestCase.example')
	at org.springframework.test.context.bean.override.BeanOverrideBeanFactoryPostProcessor.registerReplaceDefinition(BeanOverrideBeanFactoryPostProcessor.java:143) ~[main/:?]
	at org.springframework.test.context.bean.override.BeanOverrideBeanFactoryPostProcessor.registerBeanOverride(BeanOverrideBeanFactoryPostProcessor.java:123) ~[main/:?]
	at org.springframework.test.context.bean.override.BeanOverrideBeanFactoryPostProcessor.postProcessWithRegistry(BeanOverrideBeanFactoryPostProcessor.java:99) ~[main/:?]
	at org.springframework.test.context.bean.override.BeanOverrideBeanFactoryPostProcessor.postProcessBeanFactory(BeanOverrideBeanFactoryPostProcessor.java:89) ~[main/:?]
	at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(PostProcessorRegistrationDelegate.java:363) ~[main/:?]
	at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(PostProcessorRegistrationDelegate.java:197) ~[main/:?]
	at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:790) ~[main/:?]
	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:608) ~[main/:?]
	at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:221) ~[main/:?]
	at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:110) ~[main/:?]
	at org.springframework.test.context.support.AbstractDelegatingSmartContextLoader.loadContext(AbstractDelegatingSmartContextLoader.java:212) ~[main/:?]
	at org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContextInternal(DefaultCacheAwareContextLoaderDelegate.java:225) ~[main/:?]
	at org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:152) ~[main/:?]
	... 72 more

There's even an integration test to assert the (faulty) scenario.

Metadata

Metadata

Assignees

Labels

in: testIssues in the test moduletype: bugA general bug

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions