Further emphasize @⁠Configuration classes over XML and Groovy in testing chapter

See gh-36393

Author: sbrannen

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]

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.