@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.
@SpringJUnitConfig, 
@SpringJUnitWebConfig, 
@ContextHierarchy, 
@ActiveProfiles, 
@TestPropertySource, 
SmartContextLoader, 
ContextConfigurationAttributes, 
MergedContextConfiguration, 
ApplicationContext| Modifier and Type | Optional Element and Description | 
|---|---|
| Class<?>[] | classesThe component classes to use for loading an
  ApplicationContext. | 
| boolean | inheritInitializersWhether or not context initializers from test
 superclasses should be inherited. | 
| boolean | inheritLocationsWhether or not resource locations or
 component classes from test superclasses
 should be inherited. | 
| Class<? extends ApplicationContextInitializer<?>>[] | initializersThe application context initializer classes to use for initializing
 a  ConfigurableApplicationContext. | 
| Class<? extends ContextLoader> | loader | 
| String[] | locationsThe resource locations to use for loading an
  ApplicationContext. | 
| String | nameThe name of the context hierarchy level represented by this configuration. | 
| String[] | valueAlias 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. 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 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.
 
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. 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 to false, the initializers
 for the annotated test class will shadow and effectively replace
 any initializers defined by superclasses.
 
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
 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 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
 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.