The Spring TestContext Framework (found in the org.springframework.test.context package provides general, annotation-driven support for unit and integration testing that is independent of the test framework being used. The TestContext framework also places greater emphasis on convention rather than configuration, with reasonable defaults that can be changed using annotation-based configuration.

In addition to the general testing infrastructure, the TestContext framework provides explicit support for JUnit 4, JUnit Jupiter (aka JUnit 5) and TestNG. abstract helper classes are provided for JUnit 4 and TestNG Spring. Moreover, Spring provides a special Runner from JUnit and special Rules from JUnit for JUnit 4 and a special Extension for JUnit Jupiter, which allow you to write so-called POJO test classes. POJO test classes do not necessarily extend a specific class hierarchy, such as abstract helper classes.

The next section briefly examines the internal components of the TestContext framework. If you're only interested in using the framework and don't need to extend it with your own custom listeners or loaders, skip directly to the sections on configuration (context management, dependency injection, transaction management), helper classes, and annotation support.

See the mentioned sections in "Helper classes of the TestContext framework".

Key abstractions

The core of the framework consists of the TestContextManager class and the TestContext, TestExecutionListener and SmartContextLoader interfaces. A TestContextManager interface is created for each test class (for example, to execute all test methods within one test class in JUnit Jupiter). The TestContextManager interface, in turn, manages the TestContext, which contains the context of the current test. The TestContextManager interface also updates the TestContext state as the test runs and delegates work to TestExecutionListener implementations that instrument the actual test execution, providing dependency injection, transaction management, and etc. The SmartContextLoader interface is responsible for loading the ApplicationContext for a given test class. For more information and examples of different implementations, see javadoc and the Spring test suite.

Java webinar

TestContext

TheTestContext interface encapsulates the context in which the test is running (regardless of the actual test framework being used) and provides context management as well as caching support for the test instance for which it is responsible. The TestContext interface also delegates to the SmartContextLoader to load the ApplicationContext upon request.

TestContextManager

The TestContextManager interface is the main entry point into the Spring TestContext Framework and is responsible for managing a single TestContext and signaling events to each registered TestExecutionListener at well-defined points test execution :

  • Before any "before classes" or "before all" methods of a particular test framework.

  • Post-processing of the test instance.

  • Before any "before" or "before each" methods of a particular test framework.

  • Immediately before the test method is executed, but after the test is configured.

  • Immediately after the test method is executed, but before the test is destroyed.

  • After any "after" or "after each" methods of a particular test framework.

  • After any "after class" or "after all" methods of a particular test framework.

TestExecutionListener

TheTestExecutionListener listener defines an API for responding to test execution events published by the TestContextManager with which the listener is registered. See TestExecutionListener configuration.

Context Loaders

ContextLoader is a strategy interface for loading ApplicationContext for an integration test managed by the Spring TestContext Framework. You need to implement SmartContextLoader instead of this interface to provide support for component classes, active bean definition profiles, test property sources, context hierarchies, and WebApplicationContext support.

SmartContextLoader is an extension of the ContextLoader interface that replaces the original simple SPI ContextLoader interface. Specifically, SmartContextLoader can choose to handle resource locations, component classes, or context initializers. In addition, SmartContextLoader can set active bean definition profiles and test property sources in the loaded context.

Spring provides the following implementations:

  • DelegatingSmartContextLoader: One of the two default loaders, it internally delegates work to the AnnotationConfigContextLoader, GenericXmlContextLoader or GenericGroovyXmlContextLoader loaders , depending either on the configuration declared for the test class or on the presence of default locations or default configuration classes. Groovy support is enabled only if Groovy is on the classpath.

  • WebDelegatingSmartContextLoader: One of the two default loaders, it internally delegates work to the AnnotationConfigWebContextLoader, GenericXmlWebContextLoader or GenericGroovyXmlWebContextLoader loaders depending either on the configuration declared for the test class or on the presence of default locations or default configuration classes. The web loader ContextLoader is only used if the test class has the @WebAppConfiguration annotation. Groovy support is enabled only if Groovy is on the classpath.

  • AnnotationConfigContextLoader: Loads the standard ApplicationContext from component classes.

  • AnnotationConfigWebContextLoader: Loads the WebApplicationContext from component classes.

  • GenericGroovyXmlContextLoader: Loads a standard ApplicationContext from resources, which are either Groovy scripts or XML configuration files.

  • GenericGroovyXmlWebContextLoader: Loads the WebApplicationContext from resources, which are either Groovy scripts or XML configuration files.

  • GenericXmlContextLoader: Loads the standard ApplicationContext from XML resource locations.

  • GenericXmlWebContextLoader: Loads WebApplicationContext from XML resource locations.

Initial loading of the TestContext framework

The default configuration for the Spring TestContext Framework internals is sufficient for all common use cases. However, there are times when a development team or a third-party framework needs to change the standard ContextLoader, implement a custom TestContext or ContextCache, or supplement the standard sets of ContextCustomizerFactory implementations and TestExecutionListener and so on. To provide this low-level control over the operation of the TestContext framework, the Spring framework provides a bootstrap strategy.

TestContextBootstrapper defines an SPI interface for loading the TestContext framework. The TestContextBootstrapper is used by the TestContextManager to load TestExecutionListener implementations for the current test and to build the TestContext that it manages. You can configure a custom bootstrap strategy for a test class (or test class hierarchy) by specifying the @BootstrapWith annotation either directly or as a meta annotation. If the bootstrapper is not explicitly configured with the @BootstrapWith annotation, either the DefaultTestContextBootstrapper or the WebTestContextBootstrapper is used, depending on the presence of the @WebAppConfiguration annotation.

Because the TestContextBootstrapper SPI interface is likely to change in the future (to accommodate new requirements), we strongly encourage developers not to implement this interface directly, but instead extend AbstractTestContextBootstrapper or one of its specific subclasses.