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.
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 theAnnotationConfigContextLoader
,GenericXmlContextLoader
orGenericGroovyXmlContextLoader
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 theAnnotationConfigWebContextLoader
,GenericXmlWebContextLoader
orGenericGroovyXmlWebContextLoader
loaders depending either on the configuration declared for the test class or on the presence of default locations or default configuration classes. The web loaderContextLoader
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 standardApplicationContext
from component classes. -
AnnotationConfigWebContextLoader
: Loads theWebApplicationContext
from component classes. -
GenericGroovyXmlContextLoader
: Loads a standardApplicationContext
from resources, which are either Groovy scripts or XML configuration files. -
GenericGroovyXmlWebContextLoader
: Loads theWebApplicationContext
from resources, which are either Groovy scripts or XML configuration files. -
GenericXmlContextLoader
: Loads the standardApplicationContext
from XML resource locations. -
GenericXmlWebContextLoader
: LoadsWebApplicationContext
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.