From f0451294de42ad655503b1a49c11446ca8d2f3f3 Mon Sep 17 00:00:00 2001 From: Sam Brannen Date: Thu, 9 Jun 2016 17:03:44 +0200 Subject: [PATCH] Improve formatting for test annotations in reference manual --- src/asciidoc/testing.adoc | 441 ++++++++++++-------------------------- 1 file changed, 138 insertions(+), 303 deletions(-) diff --git a/src/asciidoc/testing.adoc b/src/asciidoc/testing.adoc index b00511986de..2fd66dc9428 100644 --- a/src/asciidoc/testing.adoc +++ b/src/asciidoc/testing.adoc @@ -331,24 +331,17 @@ you can use in your unit and integration tests in conjunction with the TestConte framework. Refer to the corresponding javadocs for further information, including default attribute values, attribute aliases, and so on. -* `@ContextConfiguration` - -+ - -Defines class-level metadata that is used to determine how to load and configure an -`ApplicationContext` for integration tests. Specifically, `@ContextConfiguration` -declares the application context resource `locations` or the annotated `classes` -that will be used to load the context. - -+ +===== @ContextConfiguration +`@ContextConfiguration` defines class-level metadata that is used to determine how to +load and configure an `ApplicationContext` for integration tests. Specifically, +`@ContextConfiguration` declares the application context resource `locations` or the +annotated `classes` that will be used to load the context. Resource locations are typically XML configuration files or Groovy scripts located in the classpath; whereas, annotated classes are typically `@Configuration` classes. However, resource locations can also refer to files and scripts in the file system, and annotated classes can be component classes, etc. -+ - [source,java,indent=0] [subs="verbatim,quotes"] ---- @@ -358,8 +351,6 @@ classes can be component classes, etc. } ---- -+ - [source,java,indent=0] [subs="verbatim,quotes"] ---- @@ -369,13 +360,9 @@ classes can be component classes, etc. } ---- -+ - As an alternative or in addition to declaring resource locations or annotated classes, `@ContextConfiguration` may be used to declare `ApplicationContextInitializer` classes. -+ - [source,java,indent=0] [subs="verbatim,quotes"] ---- @@ -385,15 +372,11 @@ As an alternative or in addition to declaring resource locations or annotated cl } ---- -+ - `@ContextConfiguration` may optionally be used to declare the `ContextLoader` strategy as well. Note, however, that you typically do not need to explicitly configure the loader since the default loader supports either resource `locations` or annotated `classes` as well as `initializers`. -+ - [source,java,indent=0] [subs="verbatim,quotes"] ---- @@ -403,8 +386,6 @@ loader since the default loader supports either resource `locations` or annotate } ---- -+ - [NOTE] ==== `@ContextConfiguration` provides support for __inheriting__ resource locations or @@ -412,24 +393,18 @@ configuration classes as well as context initializers declared by superclasses b default. ==== -+ - See <> and the `@ContextConfiguration` javadocs for further details. -* `@WebAppConfiguration` - -+ - -A class-level annotation that is used to declare that the `ApplicationContext` loaded -for an integration test should be a `WebApplicationContext`. The mere presence of -`@WebAppConfiguration` on a test class ensures that a `WebApplicationContext` will be -loaded for the test, using the default value of `"file:src/main/webapp"` for the path to -the root of the web application (i.e., the __resource base path__). The resource base -path is used behind the scenes to create a `MockServletContext` which serves as the -`ServletContext` for the test's `WebApplicationContext`. - -+ +===== @WebAppConfiguration +`@WebAppConfiguration` is a class-level annotation that is used to declare that the +`ApplicationContext` loaded for an integration test should be a `WebApplicationContext`. +The mere presence of `@WebAppConfiguration` on a test class ensures that a +`WebApplicationContext` will be loaded for the test, using the default value of +`"file:src/main/webapp"` for the path to the root of the web application (i.e., the +__resource base path__). The resource base path is used behind the scenes to create a +`MockServletContext` which serves as the `ServletContext` for the test's +`WebApplicationContext`. [source,java,indent=0] [subs="verbatim,quotes"] @@ -441,14 +416,10 @@ path is used behind the scenes to create a `MockServletContext` which serves as } ---- -+ - To override the default, specify a different base resource path via the __implicit__ `value` attribute. Both `classpath:` and `file:` resource prefixes are supported. If no resource prefix is supplied the path is assumed to be a file system resource. -+ - [source,java,indent=0] [subs="verbatim,quotes"] ---- @@ -459,26 +430,17 @@ resource prefix is supplied the path is assumed to be a file system resource. } ---- -+ - Note that `@WebAppConfiguration` must be used in conjunction with `@ContextConfiguration`, either within a single test class or within a test class hierarchy. See the `@WebAppConfiguration` javadocs for further details. -+ - -* `@ContextHierarchy` - -+ - -A class-level annotation that is used to define a hierarchy of ++ApplicationContext++s -for integration tests. `@ContextHierarchy` should be declared with a list of one or more -`@ContextConfiguration` instances, each of which defines a level in the context -hierarchy. The following examples demonstrate the use of `@ContextHierarchy` within a -single test class; however, `@ContextHierarchy` can also be used within a test class -hierarchy. - -+ +===== @ContextHierarchy +`@ContextHierarchy` is a class-level annotation that is used to define a hierarchy of +++ApplicationContext++s for integration tests. `@ContextHierarchy` should be declared +with a list of one or more `@ContextConfiguration` instances, each of which defines a +level in the context hierarchy. The following examples demonstrate the use of +`@ContextHierarchy` within a single test class; however, `@ContextHierarchy` can also be +used within a test class hierarchy. [source,java,indent=0] [subs="verbatim,quotes"] @@ -492,8 +454,6 @@ hierarchy. } ---- -+ - [source,java,indent=0] [subs="verbatim,quotes"] ---- @@ -507,8 +467,6 @@ hierarchy. } ---- -+ - If you need to merge or override the configuration for a given level of the context hierarchy within a test class hierarchy, you must explicitly name that level by supplying the same value to the `name` attribute in `@ContextConfiguration` at each @@ -516,14 +474,10 @@ corresponding level in the class hierarchy. See <> and the `@ContextHierarchy` javadocs for further examples. -* `@ActiveProfiles` - -+ - -A class-level annotation that is used to declare which __bean definition profiles__ -should be active when loading an `ApplicationContext` for test classes. - -+ +===== @ActiveProfiles +`@ActiveProfiles` is a class-level annotation that is used to declare which __bean +definition profiles__ should be active when loading an `ApplicationContext` for an +integration test. [source,java,indent=0] [subs="verbatim,quotes"] @@ -535,8 +489,6 @@ should be active when loading an `ApplicationContext` for test classes. } ---- -+ - [source,java,indent=0] [subs="verbatim,quotes"] ---- @@ -547,8 +499,6 @@ should be active when loading an `ApplicationContext` for test classes. } ---- -+ - [NOTE] ==== `@ActiveProfiles` provides support for __inheriting__ active bean definition profiles @@ -558,20 +508,13 @@ definition profiles programmatically by implementing a custom and registering it via the `resolver` attribute of `@ActiveProfiles`. ==== -+ - See <> and the `@ActiveProfiles` javadocs for examples and further details. -* `@TestPropertySource` - -+ - -A class-level annotation that is used to configure the locations of properties files and -inlined properties to be added to the set of `PropertySources` in the `Environment` for -an `ApplicationContext` loaded for an integration test. - -+ +===== @TestPropertySource +`@TestPropertySource` is a class-level annotation that is used to configure the locations +of properties files and inlined properties to be added to the set of `PropertySources` in +the `Environment` for an `ApplicationContext` loaded for an integration test. Test property sources have higher precedence than those loaded from the operating system's environment or Java system properties as well as property sources added by the @@ -580,12 +523,8 @@ sources can be used to selectively override properties defined in system and app property sources. Furthermore, inlined properties have higher precedence than properties loaded from resource locations. -+ - The following example demonstrates how to declare a properties file from the classpath. -+ - [source,java,indent=0] [subs="verbatim,quotes"] ---- @@ -596,12 +535,8 @@ The following example demonstrates how to declare a properties file from the cla } ---- -+ - The following example demonstrates how to declare _inlined_ properties. -+ - [source,java,indent=0] [subs="verbatim,quotes"] ---- @@ -612,32 +547,23 @@ The following example demonstrates how to declare _inlined_ properties. } ---- -* `@DirtiesContext` - -+ - -Indicates that the underlying Spring `ApplicationContext` has been __dirtied__ during -the execution of a test (i.e., modified or corrupted in some manner -- for example, by -changing the state of a singleton bean) and should be closed. When an application -context is marked __dirty__, it is removed from the testing framework's cache and -closed. As a consequence, the underlying Spring container will be rebuilt for any +===== @DirtiesContext +`@DirtiesContext` indicates that the underlying Spring `ApplicationContext` has been +__dirtied__ during the execution of a test (i.e., modified or corrupted in some manner -- +for example, by changing the state of a singleton bean) and should be closed. When an +application context is marked __dirty__, it is removed from the testing framework's cache +and closed. As a consequence, the underlying Spring container will be rebuilt for any subsequent test that requires a context with the same configuration metadata. -+ - `@DirtiesContext` can be used as both a class-level and method-level annotation within the same class or class hierarchy. In such scenarios, the `ApplicationContext` is marked as __dirty__ before or after any such annotated method as well as before or after the current test class, depending on the configured `methodMode` and `classMode`. -+ - The following examples explain when the context would be dirtied for various configuration scenarios: -+ - -** Before the current test class, when declared on a class with class mode set to +* Before the current test class, when declared on a class with class mode set to `BEFORE_CLASS`. + @@ -653,7 +579,7 @@ configuration scenarios: + -** After the current test class, when declared on a class with class mode set to +* After the current test class, when declared on a class with class mode set to `AFTER_CLASS` (i.e., the default class mode). + @@ -669,7 +595,7 @@ configuration scenarios: + -** Before each test method in the current test class, when declared on a class with class +* Before each test method in the current test class, when declared on a class with class mode set to `BEFORE_EACH_TEST_METHOD.` + @@ -685,7 +611,7 @@ mode set to `BEFORE_EACH_TEST_METHOD.` + -** After each test method in the current test class, when declared on a class with class +* After each test method in the current test class, when declared on a class with class mode set to `AFTER_EACH_TEST_METHOD.` + @@ -701,7 +627,7 @@ mode set to `AFTER_EACH_TEST_METHOD.` + -** Before the current test, when declared on a method with the method mode set to +* Before the current test, when declared on a method with the method mode set to `BEFORE_METHOD`. + @@ -718,7 +644,7 @@ mode set to `AFTER_EACH_TEST_METHOD.` + -** After the current test, when declared on a method with the method mode set to +* After the current test, when declared on a method with the method mode set to `AFTER_METHOD` (i.e., the default method mode). + @@ -733,8 +659,6 @@ mode set to `AFTER_EACH_TEST_METHOD.` } ---- -+ - If `@DirtiesContext` is used in a test whose context is configured as part of a context hierarchy via `@ContextHierarchy`, the `hierarchyMode` flag can be used to control how the context cache is cleared. By default an __exhaustive__ algorithm will be used that @@ -745,8 +669,6 @@ will be removed from the context cache and closed. If the __exhaustive__ algorit overkill for a particular use case, the simpler __current level__ algorithm can be specified instead, as seen below. -+ - [source,java,indent=0] [subs="verbatim,quotes"] ---- @@ -768,20 +690,14 @@ specified instead, as seen below. } ---- -+ - For further details regarding the `EXHAUSTIVE` and `CURRENT_LEVEL` algorithms see the `DirtiesContext.HierarchyMode` javadocs. -* `@TestExecutionListeners` - -+ - -Defines class-level metadata for configuring which ++TestExecutionListener++s should be -registered with the `TestContextManager`. Typically, `@TestExecutionListeners` is used -in conjunction with `@ContextConfiguration`. - -+ +===== @TestExecutionListeners +`@TestExecutionListeners` defines class-level metadata for configuring the +`TestExecutionListener` implementations that should be registered with the +`TestContextManager`. Typically, `@TestExecutionListeners` is used in conjunction with +`@ContextConfiguration`. [source,java,indent=0] [subs="verbatim,quotes"] @@ -793,23 +709,15 @@ in conjunction with `@ContextConfiguration`. } ---- -+ - -`@TestExecutionListeners` supports __inherited__ listeners by default. See the javadocs +`@TestExecutionListeners` supports _inherited_ listeners by default. See the javadocs for an example and further details. -+ - -* `@Commit` - -+ - -Indicates that the transaction for a transactional test method should be __committed__ -after the test method has completed. `@Commit` can be used as a direct replacement for -`@Rollback(false)` in order to more explicitly convey the intent of the code. Analogous to -`@Rollback`, `@Commit` may also be declared as a class-level or method-level annotation. - -+ +===== @Commit +`@Commit` indicates that the transaction for a transactional test method should be +__committed__ after the test method has completed. `@Commit` can be used as a direct +replacement for `@Rollback(false)` in order to more explicitly convey the intent of the +code. Analogous to `@Rollback`, `@Commit` may also be declared as a class-level or +method-level annotation. [source,java,indent=0] [subs="verbatim,quotes"] @@ -821,25 +729,18 @@ after the test method has completed. `@Commit` can be used as a direct replaceme } ---- -* `@Rollback` - -+ - -Indicates whether the transaction for a transactional test method should be __rolled -back__ after the test method has completed. If `true`, the transaction is rolled back; -otherwise, the transaction is committed (see also `@Commit`). Rollback semantics for -integration tests in the Spring TestContext Framework default to `true` even if +===== @Rollback +`@Rollback` indicates whether the transaction for a transactional test method should be +__rolled back__ after the test method has completed. If `true`, the transaction is rolled +back; otherwise, the transaction is committed (see also `@Commit`). Rollback semantics +for integration tests in the Spring TestContext Framework default to `true` even if `@Rollback` is not explicitly declared. -+ - When declared as a class-level annotation, `@Rollback` defines the default rollback semantics for all test methods within the test class hierarchy. When declared as a method-level annotation, `@Rollback` defines rollback semantics for the specific test method, potentially overriding class-level `@Rollback` or `@Commit` semantics. -+ - [source,java,indent=0] [subs="verbatim,quotes"] ---- @@ -850,18 +751,12 @@ method, potentially overriding class-level `@Rollback` or `@Commit` semantics. } ---- -* `@BeforeTransaction` - -+ - -Indicates that the annotated `void` method should be executed __before__ a transaction -is started for test methods configured to run within a transaction via Spring's -`@Transactional` annotation. As of Spring Framework 4.3, `@BeforeTransaction` methods -are not required to be `public` and may be declared on Java 8 based interface default -methods. - - -+ +===== @BeforeTransaction +`@BeforeTransaction` indicates that the annotated `void` method should be executed +__before__ a transaction is started for test methods configured to run within a +transaction via Spring's `@Transactional` annotation. As of Spring Framework 4.3, +`@BeforeTransaction` methods are not required to be `public` and may be declared on Java +8 based interface default methods. [source,java,indent=0] [subs="verbatim,quotes"] @@ -872,17 +767,12 @@ methods. } ---- -* `@AfterTransaction` - -+ - -Indicates that the annotated `void` method should be executed __after__ a transaction -is ended for test methods configured to run within a transaction via Spring's -`@Transactional` annotation. As of Spring Framework 4.3, `@AfterTransaction` methods -are not required to be `public` and may be declared on Java 8 based interface default -methods. - -+ +===== @AfterTransaction +`@AfterTransaction` indicates that the annotated `void` method should be executed +__after__ a transaction is ended for test methods configured to run within a transaction +via Spring's `@Transactional` annotation. As of Spring Framework 4.3, `@AfterTransaction` +methods are not required to be `public` and may be declared on Java 8 based interface +default methods. [source,java,indent=0] [subs="verbatim,quotes"] @@ -893,14 +783,9 @@ methods. } ---- -* `@Sql` - -+ - -Used to annotate a test class or test method to configure SQL scripts to be executed -against a given database during integration tests. - -+ +===== @Sql +`@Sql` is used to annotate a test class or test method to configure SQL scripts to be +executed against a given database during integration tests. [source,java,indent=0] [subs="verbatim,quotes"] @@ -912,18 +797,11 @@ against a given database during integration tests. } ---- -+ - See <> for further details. -* `@SqlConfig` - -+ - -Defines metadata that is used to determine how to parse and execute SQL scripts -configured via the `@Sql` annotation. - -+ +===== @SqlConfig +`@SqlConfig` defines metadata that is used to determine how to parse and execute SQL +scripts configured via the `@Sql` annotation. [source,java,indent=0] [subs="verbatim,quotes"] @@ -938,16 +816,12 @@ configured via the `@Sql` annotation. } ---- -* `@SqlGroup` - -+ - -A container annotation that aggregates several `@Sql` annotations. Can be used natively, -declaring several nested `@Sql` annotations. Can also be used in conjunction with Java -8's support for repeatable annotations, where `@Sql` can simply be declared several times -on the same class or method, implicitly generating this container annotation. - -+ +===== @SqlGroup +`@SqlGroup` is a container annotation that aggregates several `@Sql` annotations. +`@SqlGroup` can be used natively, declaring several nested `@Sql` annotations, or it can +be used in conjunction with Java 8's support for repeatable annotations, where `@Sql` can +simply be declared several times on the same class or method, implicitly generating this +container annotation. [source,java,indent=0] [subs="verbatim,quotes"] @@ -1002,15 +876,11 @@ The following annotations are __only__ supported when used in conjunction with t <>, <>, or <>. -* `@IfProfileValue` - -+ - -Indicates that the annotated test is enabled for a specific testing environment. If the -configured `ProfileValueSource` returns a matching `value` for the provided `name`, the -test is enabled. Otherwise, the test will be disabled and effectively _ignored_. - -+ +===== @IfProfileValue +`@IfProfileValue` indicates that the annotated test is enabled for a specific testing +environment. If the configured `ProfileValueSource` returns a matching `value` for the +provided `name`, the test is enabled. Otherwise, the test will be disabled and +effectively _ignored_. `@IfProfileValue` can be applied at the class level, the method level, or both. Class-level usage of `@IfProfileValue` takes precedence over method-level usage for any @@ -1020,8 +890,6 @@ enabled both at the class level _and_ at the method level; the absence of semantics of JUnit 4's `@Ignore` annotation, except that the presence of `@Ignore` always disables a test. -+ - [source,java,indent=0] [subs="verbatim,quotes"] ---- @@ -1032,14 +900,10 @@ disables a test. } ---- -+ - Alternatively, you can configure `@IfProfileValue` with a list of `values` (with __OR__ semantics) to achieve TestNG-like support for __test groups__ in a JUnit 4 environment. Consider the following example: -+ - [source,java,indent=0] [subs="verbatim,quotes"] ---- @@ -1050,18 +914,11 @@ Consider the following example: } ---- -+ - -* `@ProfileValueSourceConfiguration` - -+ - -Class-level annotation that specifies what type of `ProfileValueSource` to use when -retrieving __profile values__ configured through the `@IfProfileValue` annotation. If -`@ProfileValueSourceConfiguration` is not declared for a test, -`SystemProfileValueSource` is used by default. - -+ +===== @ProfileValueSourceConfiguration +`@ProfileValueSourceConfiguration` is a class-level annotation that specifies what type +of `ProfileValueSource` to use when retrieving __profile values__ configured through the +`@IfProfileValue` annotation. If `@ProfileValueSourceConfiguration` is not declared for a +test, `SystemProfileValueSource` is used by default. [source,java,indent=0] [subs="verbatim,quotes"] @@ -1072,21 +929,14 @@ retrieving __profile values__ configured through the `@IfProfileValue` annotatio } ---- -* `@Timed` - -+ - -Indicates that the annotated test method must finish execution in a specified time -period (in milliseconds). If the text execution time exceeds the specified time period, -the test fails. - -+ +===== @Timed +`@Timed` indicates that the annotated test method must finish execution in a specified +time period (in milliseconds). If the text execution time exceeds the specified time +period, the test fails. The time period includes execution of the test method itself, any repetitions of the test (see `@Repeat`), as well as any __set up__ or __tear down__ of the test fixture. -+ - [source,java,indent=0] [subs="verbatim,quotes"] ---- @@ -1096,8 +946,6 @@ test (see `@Repeat`), as well as any __set up__ or __tear down__ of the test fix } ---- -+ - Spring's `@Timed` annotation has different semantics than JUnit 4's `@Test(timeout=...)` support. Specifically, due to the manner in which JUnit 4 handles test execution timeouts (that is, by executing the test method in a separate `Thread`), `@Test(timeout=...)` @@ -1105,20 +953,13 @@ preemptively fails the test if the test takes too long. Spring's `@Timed`, on th hand, does not preemptively fail the test but rather waits for the test to complete before failing. -* `@Repeat` - -+ - -Indicates that the annotated test method must be executed repeatedly. The number of -times that the test method is to be executed is specified in the annotation. - -+ +===== @Repeat +`@Repeat` indicates that the annotated test method must be executed repeatedly. The +number of times that the test method is to be executed is specified in the annotation. The scope of execution to be repeated includes execution of the test method itself as well as any __set up__ or __tear down__ of the test fixture. -+ - [source,java,indent=0] [subs="verbatim,quotes"] ---- @@ -1132,9 +973,9 @@ well as any __set up__ or __tear down__ of the test fixture. [[integration-testing-annotations-meta]] ==== Meta-Annotation Support for Testing -Since Spring Framework 4.0, it is possible to use test-related annotations as -<> in order to create custom _composed annotations_ -and reduce configuration duplication across a test suite. +It is possible to use most test-related annotations as +<> in order to create custom _composed +annotations_ and reduce configuration duplication across a test suite. Each of the following may be used as meta-annotations in conjunction with the <>. @@ -1248,76 +1089,70 @@ is responsible for loading an `ApplicationContext` for a given test class. Consu javadocs and the Spring test suite for further information and examples of various implementations. -* `TestContext`: Encapsulates the context in which a test is executed, agnostic of the - actual testing framework in use, and provides context management and caching support - for the test instance for which it is responsible. The `TestContext` also delegates to a - `SmartContextLoader` to load an `ApplicationContext` if requested. -* `TestContextManager`: The main entry point into the __Spring TestContext Framework__, - which manages a single `TestContext` and signals events to each registered - `TestExecutionListener` at well-defined test execution points: -** prior to any __before class__ or __before all__ methods of a particular testing framework -** test instance post-processing -** prior to any __before__ or __before each__ methods of a particular testing framework -** after any __after__ or __after each__ methods of a particular testing framework -** after any __after class__ or __after all__ methods of a particular testing framework -* `TestExecutionListener`: Defines the API for reacting to test execution - events published by the `TestContextManager` with which the listener is registered. See - <>. -* `ContextLoader`: Strategy interface introduced in Spring 2.5 for loading an - `ApplicationContext` for an integration test managed by the Spring TestContext - Framework. +===== TestContext +`TestContext` encapsulates the context in which a test is executed, agnostic of the +actual testing framework in use, and provides context management and caching support for +the test instance for which it is responsible. The `TestContext` also delegates to a +`SmartContextLoader` to load an `ApplicationContext` if requested. -+ +===== TestContextManager +`TestContextManager` is the main entry point into the __Spring TestContext Framework__, +which manages a single `TestContext` and signals events to each registered +`TestExecutionListener` at well-defined test execution points: +* prior to any __before class__ or __before all__ methods of a particular testing framework +* test instance post-processing +* prior to any __before__ or __before each__ methods of a particular testing framework +* after any __after__ or __after each__ methods of a particular testing framework +* after any __after class__ or __after all__ methods of a particular testing framework + +===== TestExecutionListener +`TestExecutionListener` defines the API for reacting to test execution events published +by the `TestContextManager` with which the listener is registered. See +<>. + +===== Context Loaders +`ContextLoader` is a strategy interface that was introduced in Spring 2.5 for loading an +`ApplicationContext` for an integration test managed by the Spring TestContext Framework. Implement `SmartContextLoader` instead of this interface in order to provide support for annotated classes, active bean definition profiles, test property sources, context hierarchies, and `WebApplicationContext` support. -* `SmartContextLoader`: Extension of the `ContextLoader` interface introduced in Spring - 3.1. - -+ - -The `SmartContextLoader` SPI supersedes the `ContextLoader` SPI that was introduced in -Spring 2.5. Specifically, a `SmartContextLoader` can choose to process resource -`locations`, annotated `classes`, or context `initializers`. Furthermore, a +`SmartContextLoader` is an extension of the `ContextLoader` interface introduced in +Spring 3.1. The `SmartContextLoader` SPI supersedes the `ContextLoader` SPI that was +introduced in Spring 2.5. Specifically, a `SmartContextLoader` can choose to process +resource `locations`, annotated `classes`, or context `initializers`. Furthermore, a `SmartContextLoader` can set active bean definition profiles and test property sources in the context that it loads. -+ - Spring provides the following implementations: -+ - -** `DelegatingSmartContextLoader`: one of two default loaders which delegates internally +* `DelegatingSmartContextLoader`: one of two default loaders which delegates internally to an `AnnotationConfigContextLoader`, a `GenericXmlContextLoader`, or a `GenericGroovyXmlContextLoader` depending either on the configuration declared for the test class or on the presence of default locations or default configuration classes. Groovy support is only enabled if Groovy is on the classpath. -** `WebDelegatingSmartContextLoader`: one of two default loaders which delegates +* `WebDelegatingSmartContextLoader`: one of two default loaders which delegates internally to an `AnnotationConfigWebContextLoader`, a `GenericXmlWebContextLoader`, or a `GenericGroovyXmlWebContextLoader` depending either on the configuration declared for the test class or on the presence of default locations or default configuration classes. A web `ContextLoader` will only be used if `@WebAppConfiguration` is present on the test class. Groovy support is only enabled if Groovy is on the classpath. -** `AnnotationConfigContextLoader`: loads a standard `ApplicationContext` from +* `AnnotationConfigContextLoader`: loads a standard `ApplicationContext` from __annotated classes__. -** `AnnotationConfigWebContextLoader`: loads a `WebApplicationContext` from __annotated +* `AnnotationConfigWebContextLoader`: loads a `WebApplicationContext` from __annotated classes__. -** `GenericGroovyXmlContextLoader`: loads a standard `ApplicationContext` from __resource +* `GenericGroovyXmlContextLoader`: loads a standard `ApplicationContext` from __resource locations__ that are either Groovy scripts or XML configuration files. -** `GenericGroovyXmlWebContextLoader`: loads a `WebApplicationContext` from __resource +* `GenericGroovyXmlWebContextLoader`: loads a `WebApplicationContext` from __resource locations__ that are either Groovy scripts or XML configuration files. -** `GenericXmlContextLoader`: loads a standard `ApplicationContext` from XML __resource +* `GenericXmlContextLoader`: loads a standard `ApplicationContext` from XML __resource locations__. -** `GenericXmlWebContextLoader`: loads a `WebApplicationContext` from XML __resource +* `GenericXmlWebContextLoader`: loads a `WebApplicationContext` from XML __resource locations__. -** `GenericPropertiesContextLoader`: loads a standard `ApplicationContext` from Java +* `GenericPropertiesContextLoader`: loads a standard `ApplicationContext` from Java Properties files. -The following sections explain how to configure the TestContext framework and provide -working examples of how to write unit and integration tests with the framework. [[testcontext-tel-config]] ==== TestExecutionListener configuration