The loadContext(*) methods in AbstractGenericContextLoader and AbstractGenericWebContextLoader invoke AnnotationConfigUtils.registerAnnotationConfigProcessors(context).
The result is that @Autowired, @Resource, @Inject, etc. all work by default, even if annotation-driven dependency injection is not explicitly configured in the test's ApplicationContext. Consequently, if a developer is not aware of this, then errors related to the lack of explicit annotation-driven DI support in production configuration will not be noticed until after testing which is typically undesirable.
Note, however, that this unexpected behavior only applies to XML-based configuration. With JavaConfig, an AnnotatedBeanDefinitionReader (used internally by AnnotationConfigContextLoader and AnnotationConfigWebContextLoader) automatically registers the annotation config processors.
Furthermore, BeanPostProcessors may inadvertently be applied to the test instance – even though the test is not truly a bean in the ApplicationContext. This leads to potentially problematic behavior such as accidental proxying of the test instance, as described in SPR-9478.
- As suggested in comments for this issue, create an ApplicationContext dedicated solely to the test instance (for the purpose of dependency injection and bean initialization) and set the parent of that context to the ApplicationContext loaded by the TCF.
- Stop invoking AnnotationConfigUtils.registerAnnotationConfigProcessors() in:
- Ensure that child contexts are properly closed with regard to context caching in the TCF.
Do not enable annotation-driven DI for the entire ApplicationContext in the TestContext framework
It would be better if the TestContext framework (TCF) only enabled annotation-driven dependency injection for test instances and not for the entire ApplicationContext.