This version is still in development and is not considered stable yet. For the latest stable version, please use Spring Framework 7.0.7!

Default Context Configuration

As explained in the sections on component classes, XML resources, and Groovy scripts, the TestContext framework will attempt to locate default context configuration if you do not explicitly specify @Configuration classes, XML configuration files, or Groovy scripts from which the test’s ApplicationContext should be loaded.

As of Spring Framework 7.1, the TestContext framework reliably detects all default context configuration within a type hierarchy or enclosing class hierarchy (for @Nested test classes) above a given test class, even if @ContextConfiguration is not declared within those hierarchies.

Prior to Spring Framework 7.1, due to a bug in the detection algorithm, default context configuration for a superclass or enclosing class was ignored if the type hierarchy or enclosing class hierarchy did not declare @ContextConfiguration. Consequently, test suites may encounter issues after the upgrade to 7.1. For example, a static nested @Configuration class in a superclass or enclosing class that was previously ignored is now processed, which may lead to unexpected beans in the resulting ApplicationContext or outright failures in tests.

To help you identify affected tests before upgrading, Spring Framework 7.0.6 and later 7.0.x versions log a warning whenever they encounter default context configuration that is ignored — for example, a @Configuration class or XML configuration file. The remainder of this section provides guidance on how to address such issues.

Annotating the affected subclass or @Nested class with @ContextConfiguration allows you to take matters into your own hands and specify which classes in the hierarchy are actually intended to contribute context configuration.

If you do not want static nested @Configuration classes to be processed, you can:

  • Remove the @Configuration declaration.

  • Apply @ContextConfiguration only where you actually want such classes to be processed.

  • Move the static nested @Configuration classes to standalone top-level classes so that they cannot be accidentally interpreted as default configuration classes.

Similarly, if you encounter issues with default XML configuration files or Groovy scripts being detected and you do not want them to be processed, you can:

  • Apply @ContextConfiguration only where you actually want such resources to be processed.

  • Rename the resource files to something that does not match the default naming convention (such as *-context.xml for XML configuration) so that they cannot be accidentally interpreted as default configuration files.

  • Move the affected resource files to a different package or filesystem location within your project.