Annotation Interface ContextConfiguration
@ContextConfiguration
defines class-level metadata that is used to determine
how to load and configure an ApplicationContext
for integration tests.
Supported Resource Types
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.
Component Classes
The term component class can refer to any of the following.
- A class annotated with
@Configuration
- A component (i.e., a class annotated with
@Component
,@Service
,@Repository
, etc.) - A JSR-330 compliant class that is annotated with
jakarta.inject
annotations - Any class that contains
@Bean
-methods - Any other class that is intended to be registered as a Spring component (i.e., a Spring bean
in the
ApplicationContext
), potentially taking advantage of automatic autowiring of a single constructor without the use of Spring annotations
ApplicationContext
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.
- Since:
- 2.5
- Author:
- Sam Brannen
- See Also:
-
Optional Element Summary
Modifier and TypeOptional ElementDescriptionClass<?>[]
The component classes to use for loading anApplicationContext
.boolean
Whether or not context initializers from test superclasses should be inherited.boolean
Whether or not resource locations or component classes from test superclasses should be inherited.Class<? extends ApplicationContextInitializer<?>>[]
The application context initializer classes to use for initializing aConfigurableApplicationContext
.Class<? extends ContextLoader>
String[]
The resource locations to use for loading anApplicationContext
.The name of the context hierarchy level represented by this configuration.String[]
Alias forlocations()
.
-
Element Details
-
value
Alias forlocations()
.This attribute may not be used in conjunction with
locations()
, but it may be used instead oflocations()
.- Since:
- 3.0
- See Also:
- Default:
- {}
-
locations
The resource locations to use for loading anApplicationContext
.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 onAbstractContextLoader.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 asGenericXmlContextLoader
orGenericGroovyXmlContextLoader
which are the effective default implementations used at runtime iflocations
are configured. See the documentation forloader()
for further details regarding default loaders.This attribute may not be used in conjunction with
value()
, but it may be used instead ofvalue()
.- Since:
- 2.5
- See Also:
- Default:
- {}
-
classes
Class<?>[] classesThe component classes to use for loading anApplicationContext
.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 forloader()
for further details regarding default loaders.- Since:
- 3.1
- See Also:
- Default:
- {}
-
initializers
Class<? extends ApplicationContextInitializer<?>>[] initializersThe application context initializer classes to use for initializing aConfigurableApplicationContext
.The concrete
ConfigurableApplicationContext
type supported by each declared initializer must be compatible with the type ofApplicationContext
created by theSmartContextLoader
in use.SmartContextLoader
implementations typically detect whether Spring'sOrdered
interface has been implemented or if the @Order
annotation is present and sort instances accordingly prior to invoking them.- Since:
- 3.2
- See Also:
- Default:
- {}
-
inheritLocations
boolean inheritLocationsWhether or not resource locations or component classes from test superclasses should be inherited.The default value is
true
. This means that an annotated test class will inherit the resource locations or component classes defined by test superclasses. 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. Thus, subclasses have the option of extending the list of resource locations or component classes.If
inheritLocations
is set tofalse
, 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.In the following example that uses path-based resource locations, the
ApplicationContext
forExtendedTest
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
forExtendedTest
will be loaded from theBaseConfig
andExtendedConfig
configuration classes, in that order. Beans defined inExtendedConfig
may therefore override those defined inBaseConfig
.@ContextConfiguration(classes=BaseConfig.class) public class BaseTest { // ... } @ContextConfiguration(classes=ExtendedConfig.class) public class ExtendedTest extends BaseTest { // ... }
- Since:
- 2.5
- Default:
- true
-
inheritInitializers
boolean inheritInitializersWhether or not context initializers from test superclasses should be inherited.The default value is
true
. This means that an annotated test class will inherit the application context initializers defined by test superclasses. Specifically, the initializers for a given test class will be added to the set of initializers defined by test superclasses. Thus, subclasses have the option of extending the set of initializers.If
inheritInitializers
is set tofalse
, the initializers for the annotated test class will shadow and effectively replace any initializers defined by superclasses.In the following example, the
ApplicationContext
forExtendedTest
will be initialized usingBaseInitializer
andExtendedInitializer
. Note, however, that the order in which the initializers are invoked depends on whether they implementOrdered
or are annotated with@Order
.@ContextConfiguration(initializers = BaseInitializer.class) public class BaseTest { // ... } @ContextConfiguration(initializers = ExtendedInitializer.class) public class ExtendedTest extends BaseTest { // ... }
- Since:
- 3.2
- Default:
- true
-
loader
Class<? extends ContextLoader> loaderThe type ofSmartContextLoader
(orContextLoader
) to use for loading anApplicationContext
.If not specified, the loader will be inherited from the first superclass that is annotated or meta-annotated with
@ContextConfiguration
and specifies an explicit loader. If no class in the hierarchy specifies an explicit loader, a default loader will be used instead.The default concrete implementation chosen at runtime will be either
DelegatingSmartContextLoader
orWebDelegatingSmartContextLoader
depending on the absence or presence of@WebAppConfiguration
. For further details on the default behavior of various concreteSmartContextLoaders
, check out the Javadoc forAbstractContextLoader
,GenericXmlContextLoader
,GenericGroovyXmlContextLoader
,AnnotationConfigContextLoader
,GenericXmlWebContextLoader
,GenericGroovyXmlWebContextLoader
, andAnnotationConfigWebContextLoader
.- Since:
- 2.5
- Default:
- org.springframework.test.context.ContextLoader.class
-
name
String nameThe name of the context hierarchy level represented by this configuration.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 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. See the Javadoc for@ContextHierarchy
for details.- Since:
- 3.2.2
- Default:
- ""
-