@Target(value=TYPE) @Retention(value=RUNTIME) @Documented @Inherited public @interface ContextConfiguration
@ContextConfiguration
defines class-level metadata that is used to determine
how to load and configure an ApplicationContext
for integration tests.
Prior to Spring 3.1, only path-based resource locations (typically XML configuration
files) were supported. As of Spring 3.1, context loaders may
choose to support either path-based or class-based resources. As of
Spring 4.0.4, context loaders may choose to support path-based
and class-based resources simultaneously. Consequently
@ContextConfiguration
can be used to declare either path-based resource
locations (via the locations()
or value()
attribute) or
component classes (via the classes()
attribute). Note, however, that most
implementations of SmartContextLoader
only support a single resource type. As
of Spring 4.1, path-based resource locations may be either XML configuration files or
Groovy scripts (if Groovy is on the classpath). Of course, third-party frameworks may
choose to support additional types of path-based resources.
The term component class can refer to any of the following.
@Configuration
@Component
,
@Service
,
@Repository
, etc.)javax.inject
annotations@Bean
-methodsApplicationContext
), potentially taking advantage of automatic autowiring of a
single constructor without the use of Spring annotationsApplicationContext
for each component
class, and such beans can therefore be injected into other beans or into the
instance of the test class.
Consult the Javadoc for @Configuration
and @Bean
for further
information regarding the configuration and semantics of component classes.
This annotation may be used as a meta-annotation to create custom composed annotations.
As of Spring Framework 5.3, this annotation will be inherited from an
enclosing test class by default. See
@NestedTestConfiguration
for details.
@SpringJUnitConfig
,
@SpringJUnitWebConfig
,
@ContextHierarchy
,
@ActiveProfiles
,
@TestPropertySource
,
SmartContextLoader
,
ContextConfigurationAttributes
,
MergedContextConfiguration
,
ApplicationContext
Modifier and Type | Optional Element and Description |
---|---|
Class<?>[] |
classes
The component classes to use for loading an
ApplicationContext . |
boolean |
inheritInitializers
Whether or not context initializers from test
superclasses and enclosing classes should be inherited.
|
boolean |
inheritLocations
Whether or not resource locations or
component classes from test superclasses
and enclosing classes should be inherited.
|
Class<? extends ApplicationContextInitializer<?>>[] |
initializers
The application context initializer classes to use for initializing
a
ConfigurableApplicationContext . |
Class<? extends ContextLoader> |
loader
|
String[] |
locations
The resource locations to use for loading an
ApplicationContext . |
String |
name
The name of the context hierarchy level represented by this configuration.
|
String[] |
value
Alias for
locations() . |
@AliasFor(value="locations") public abstract String[] value
locations()
.
This attribute may not be used in conjunction with
locations()
, but it may be used instead of locations()
.
inheritLocations()
@AliasFor(value="value") public abstract String[] locations
ApplicationContext
.
Check out the Javadoc for
AbstractContextLoader.modifyLocations()
for details on how a location
will be interpreted at runtime, in particular in case of a relative
path. Also, check out the documentation on
AbstractContextLoader.generateDefaultLocations()
for details on the
default locations that are going to be used if none are specified.
Note that the aforementioned default rules only apply for a standard
AbstractContextLoader
subclass such as
GenericXmlContextLoader
or
GenericGroovyXmlContextLoader
which are the effective default implementations used at runtime if
locations
are configured. See the documentation for loader()
for further details regarding default loaders.
This attribute may not be used in conjunction with
value()
, but it may be used instead of value()
.
inheritLocations()
public abstract Class<?>[] classes
ApplicationContext
.
Check out the javadoc for
AnnotationConfigContextLoader.detectDefaultConfigurationClasses()
for details
on how default configuration classes will be detected if no
component classes are specified. See the documentation for
loader()
for further details regarding default loaders.
Configuration
,
AnnotationConfigContextLoader
,
inheritLocations()
public abstract Class<? extends ApplicationContextInitializer<?>>[] initializers
ConfigurableApplicationContext
.
The concrete ConfigurableApplicationContext
type supported by each
declared initializer must be compatible with the type of ApplicationContext
created by the SmartContextLoader
in use.
SmartContextLoader
implementations typically detect whether
Spring's Ordered
interface has been
implemented or if the @Order
annotation is present and sort instances accordingly prior to invoking them.
ApplicationContextInitializer
,
ConfigurableApplicationContext
,
inheritInitializers()
,
loader()
public abstract boolean inheritLocations
The default value is true
. This means that an annotated test
class will inherit the resource locations or component classes
defined by test superclasses and enclosing classes. Specifically, the
resource locations or component classes for a given test class will be
appended to the list of resource locations or component classes defined
by test superclasses and enclosing classes. Thus, subclasses and nested
classes have the option of extending the list of resource
locations or component classes.
If inheritLocations
is set to false
, the
resource locations or component classes for the annotated test class
will shadow and effectively replace any resource locations
or component classes defined by superclasses and enclosing classes.
In the following example that uses path-based resource locations, the
ApplicationContext
for ExtendedTest
will be loaded from
"base-context.xml"
and
"extended-context.xml"
, in that order. Beans defined in
"extended-context.xml"
may therefore override those defined
in "base-context.xml"
.
@ContextConfiguration("base-context.xml") public class BaseTest { // ... } @ContextConfiguration("extended-context.xml") public class ExtendedTest extends BaseTest { // ... }
Similarly, in the following example that uses component classes, the
ApplicationContext
for ExtendedTest
will be loaded from the
BaseConfig
and ExtendedConfig
configuration classes, in that order. Beans defined in
ExtendedConfig
may therefore override those defined in
BaseConfig
.
@ContextConfiguration(classes=BaseConfig.class) public class BaseTest { // ... } @ContextConfiguration(classes=ExtendedConfig.class) public class ExtendedTest extends BaseTest { // ... }
public abstract boolean inheritInitializers
The default value is true
. This means that an annotated test
class will inherit the application context initializers defined
by test superclasses and enclosing classes. Specifically, the initializers
for a given test class will be added to the set of initializers defined by
test superclasses and enclosing classes. Thus, subclasses and nested classes
have the option of extending the set of initializers.
If inheritInitializers
is set to false
, the initializers
for the annotated test class will shadow and effectively replace
any initializers defined by superclasses and enclosing classes.
In the following example, the
ApplicationContext
for ExtendedTest
will be initialized using
BaseInitializer
and ExtendedInitializer
.
Note, however, that the order in which the initializers are invoked
depends on whether they implement Ordered
or are annotated with @Order
.
@ContextConfiguration(initializers = BaseInitializer.class) public class BaseTest { // ... } @ContextConfiguration(initializers = ExtendedInitializer.class) public class ExtendedTest extends BaseTest { // ... }
public abstract Class<? extends ContextLoader> loader
SmartContextLoader
(or ContextLoader
) to use
for loading an ApplicationContext
.
If not specified, the loader will be inherited from the first superclass
or enclosing class that is annotated or meta-annotated with
@ContextConfiguration
and specifies an explicit loader. If no class
in the type hierarchy or enclosing class hierarchy specifies an explicit
loader, a default loader will be used instead.
The default concrete implementation chosen at runtime will be either
DelegatingSmartContextLoader
or
WebDelegatingSmartContextLoader
depending on the absence or presence of
@WebAppConfiguration
. For further details on the default behavior
of various concrete SmartContextLoaders
, check out the Javadoc for
AbstractContextLoader
,
GenericXmlContextLoader
,
GenericGroovyXmlContextLoader
,
AnnotationConfigContextLoader
,
GenericXmlWebContextLoader
,
GenericGroovyXmlWebContextLoader
, and
AnnotationConfigWebContextLoader
.
public abstract String name
If not specified the name will be inferred based on the numerical level within all declared contexts within the hierarchy.
This attribute is only applicable when used within a test class hierarchy
or enclosing class hierarchy that is configured using
@ContextHierarchy
, in which case the name can be used for
merging or overriding this configuration with configuration
of the same name in hierarchy levels defined in superclasses or enclosing
classes. See the Javadoc for @ContextHierarchy
for
details.