## org.springframework.test.context
Annotation Type ContextConfiguration

    @Documented
    @Inherited
    @Retention(value=RUNTIME)
    @Target(value=TYPE)
    public @interface ContextConfiguration

`ContextConfiguration` defines class-level metadata that is used to determine how to load and configure an `ApplicationContext` for test classes.

Prior to Spring 3.1, only path-based resource locations were supported. As of Spring 3.1, `context loaders` may choose to support either path-based or class-based resources (but not both). Consequently `@ContextConfiguration` can be used to declare either path-based resource locations (via the `locations()` or `value()` attribute) or configuration classes (via the `classes()` attribute).

Since:
  2.5
Author:
  Sam Brannen
See Also:
  `ContextLoader`, `SmartContextLoader`, `ContextConfigurationAttributes`, `MergedContextConfiguration`, `ApplicationContext`, `ActiveProfiles`

Optional Element Summary
`Class<?>[]` `classes` The `configuration classes` to use for loading an `ApplicationContext`.
`boolean` `inheritLocations` Whether or not `resource locations` or `configuration classes` from superclasses should be inherited.
`Class<? extends ContextLoader>` `loader` The type of `ContextLoader` (or `SmartContextLoader`) to use for loading an `ApplicationContext`.
`String[]` `locations` The resource locations to use for loading an `ApplicationContext`.
`String[]` `value` Alias for `locations()`.

### value

    public abstract String[] value

  Alias for `locations()`.

  This attribute may not be used in conjunction with `locations()` or `classes()`, but it may be used instead of `locations()`.

  Since:
    3.0
  Default:
    {}

### locations

    public abstract String[] locations

  The resource locations to use for loading an `ApplicationContext`.

  Check out the Javadoc for `AbstractContextLoader.modifyLocations()` for details on how a location String 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 above-mentioned default rules only apply for a standard `AbstractContextLoader` subclass such as `GenericXmlContextLoader` which is the effective default implementation 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()` or `classes()`, but it may be used instead of `value()`.

  Since:
    2.5
  Default:
    {}

### classes

    public abstract Class<?>[] classes

  The `configuration classes` to use for loading an `ApplicationContext`.

  Check out the Javadoc for `AnnotationConfigContextLoader.detectDefaultConfigurationClasses()` for details on how default configuration classes will be detected if none are specified. See the documentation for `loader()` for further details regarding default loaders.

  This attribute may not be used in conjunction with `locations()` or `value()`.

  Since:
    3.1
  See Also:
    `Configuration`, `AnnotationConfigContextLoader`
  Default:
    {}

### inheritLocations

    public abstract boolean inheritLocations

  Whether or not `resource locations` or `configuration classes` from superclasses should be inherited.

  The default value is `true`. This means that an annotated class will inherit the resource locations or configuration classes defined by annotated superclasses. Specifically, the resource locations or configuration classes for an annotated class will be appended to the list of resource locations or configuration classes defined by annotated superclasses. Thus, subclasses have the option of extending the list of resource locations or configuration classes.

  If `inheritLocations` is set to `false`, the resource locations or configuration classes for the annotated class will shadow and effectively replace any resource locations or configuration 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 configuration 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 {
           // ...
       }

  Since:
    2.5
  Default:
    true

### loader

    public abstract Class<? extends ContextLoader> loader

  The type of `ContextLoader` (or `SmartContextLoader`) to use for loading an `ApplicationContext`.

  If not specified, the loader will be inherited from the first superclass that is 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 `DelegatingSmartContextLoader`. For further details on the default behavior of various concrete `ContextLoaders`, check out the Javadoc for `AbstractContextLoader`, `GenericXmlContextLoader`, and `AnnotationConfigContextLoader`.

  Since:
    2.5
  Default:
    org.springframework.test.context.ContextLoader.class