diff --git a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management.adoc b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management.adoc index 1ef02f8dd2b..ee120bee179 100644 --- a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management.adoc +++ b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management.adoc @@ -94,11 +94,11 @@ Dependency injection by using `@Autowired` is provided by the Test classes that use the TestContext framework do not need to extend any particular class or implement a specific interface to configure their application context. Instead, configuration is achieved by declaring the `@ContextConfiguration` annotation at the -class level. If your test class does not explicitly declare application context resource -locations or component classes, the configured `ContextLoader` determines how to load a -context from a default location or default configuration classes. In addition to context -resource locations and component classes, an application context can also be configured -through xref:testing/testcontext-framework/ctx-management/context-customizers.adoc[context customizers] +class level. If your test class does not explicitly declare component classes or resource +locations, the configured `ContextLoader` determines how to load a context from _default_ +configuration classes or a _default_ location. In addition to component classes and +context resource locations, an application context can also be configured through +xref:testing/testcontext-framework/ctx-management/context-customizers.adoc[context customizers] or xref:testing/testcontext-framework/ctx-management/initializers.adoc[context initializers]. The following sections explain how to use `@ContextConfiguration` and related annotations @@ -110,7 +110,7 @@ or context initializers. Alternatively, you can implement and configure your own * xref:testing/testcontext-framework/ctx-management/javaconfig.adoc[Context Configuration with Component Classes] * xref:testing/testcontext-framework/ctx-management/xml.adoc[Context Configuration with XML resources] * xref:testing/testcontext-framework/ctx-management/groovy.adoc[Context Configuration with Groovy Scripts] -* xref:testing/testcontext-framework/ctx-management/mixed-config.adoc[Mixing XML, Groovy Scripts, and Component Classes] +* xref:testing/testcontext-framework/ctx-management/mixed-config.adoc[Mixing Component Classes, XML, and Groovy Scripts] * xref:testing/testcontext-framework/ctx-management/context-customizers.adoc[Context Configuration with Context Customizers] * xref:testing/testcontext-framework/ctx-management/initializers.adoc[Context Configuration with Context Initializers] * xref:testing/testcontext-framework/ctx-management/inheritance.adoc[Context Configuration Inheritance] diff --git a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/mixed-config.adoc b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/mixed-config.adoc index c1b97b4a7a2..2608be393c4 100644 --- a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/mixed-config.adoc +++ b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/mixed-config.adoc @@ -1,33 +1,32 @@ [[testcontext-ctx-management-mixed-config]] -= Mixing XML, Groovy Scripts, and Component Classes += Mixing Component Classes, XML, and Groovy Scripts -It may sometimes be desirable to mix XML configuration files, Groovy scripts, and -component classes (typically `@Configuration` classes) to configure an -`ApplicationContext` for your tests. For example, if you use XML configuration in -production, you may decide that you want to use `@Configuration` classes to configure +It may sometimes be desirable to mix component classes (typically `@Configuration` +classes), XML configuration files, or Groovy scripts to configure an `ApplicationContext` +for your tests. For example, if you use XML configuration in production for legacy +reasons, you may decide that you want to use `@Configuration` classes to configure specific Spring-managed components for your tests, or vice versa. Furthermore, some third-party frameworks (such as Spring Boot) provide first-class support for loading an `ApplicationContext` from different types of resources -simultaneously (for example, XML configuration files, Groovy scripts, and -`@Configuration` classes). The Spring Framework, historically, has not supported this for -standard deployments. Consequently, most of the `SmartContextLoader` implementations that -the Spring Framework delivers in the `spring-test` module support only one resource type -for each test context. However, this does not mean that you cannot use both. One -exception to the general rule is that the `GenericGroovyXmlContextLoader` and +simultaneously (for example, `@Configuration` classes, XML configuration files, and +Groovy scripts). The Spring Framework, historically, has not supported this for standard +deployments. Consequently, most of the `SmartContextLoader` implementations that the +Spring Framework delivers in the `spring-test` module support only one resource type for +each test context. However, this does not mean that you cannot use a mixture of resource +types. One exception to the general rule is that the `GenericGroovyXmlContextLoader` and `GenericGroovyXmlWebContextLoader` support both XML configuration files and Groovy scripts simultaneously. Furthermore, third-party frameworks may choose to support the -declaration of both `locations` and `classes` through `@ContextConfiguration`, and, with +declaration of both `classes` and `locations` through `@ContextConfiguration`, and, with the standard testing support in the TestContext framework, you have the following options. -If you want to use resource locations (for example, XML or Groovy) and `@Configuration` -classes to configure your tests, you must pick one as the entry point, and that one must -include or import the other. For example, in XML or Groovy scripts, you can include -`@Configuration` classes by using component scanning or defining them as normal Spring -beans, whereas, in a `@Configuration` class, you can use `@ImportResource` to import XML -configuration files or Groovy scripts. Note that this behavior is semantically equivalent +If you want to use `@Configuration` classes and resource locations (for example, XML or +Groovy) to configure your tests, you must pick one as the entry point, and that one must +import or include the other. For example, in a `@Configuration` class, you can use +`@ImportResource` to import XML configuration files or Groovy scripts; whereas, in XML or +Groovy scripts, you can include `@Configuration` classes by using component scanning or +defining them as normal Spring beans. Note that this behavior is semantically equivalent to how you configure your application in production: In production configuration, you -define either a set of XML or Groovy resource locations or a set of `@Configuration` -classes from which your production `ApplicationContext` is loaded, but you still have the -freedom to include or import the other type of configuration. - +define either a set of `@Configuration` classes or a set of XML or Groovy resource +locations from which your production `ApplicationContext` is loaded, but you still have +the freedom to import or include the other type of configuration.