diff --git a/spring-framework-reference/src/testing.xml b/spring-framework-reference/src/testing.xml
index cc8aa8ef9e..eb1be21a6b 100644
--- a/spring-framework-reference/src/testing.xml
+++ b/spring-framework-reference/src/testing.xml
@@ -437,7 +437,7 @@
either the application context resource
locations or the
@Configuration
- classes to load as well as the
+ classes (but not both) to load as well as the
ContextLoader strategy to use for
loading the context. Note, however, that you typically do not need
to explicitly configure the loader since the default loader
@@ -1253,6 +1253,40 @@ public class OrderServiceTest {
}
+
+ Mixing XML resources and @Configuration classes
+
+ It may sometimes be desirable to mix XML resources and
+ @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
+ specific Spring-managed components for your tests, or vice versa. As
+ mentioned in the TestContext
+ framework does not allow you to declare both
+ via @ContextConfiguration, but this
+ does not mean that you cannot use both. If you want to use XML
+ and
+ @Configuration classes to configure
+ your tests, you will have to pick one as the entry
+ point, and that one will have to include or import the
+ other. For example, in XML you can include
+ @Configuration classes in component
+ scanning or define them as normal Spring beans; whereas, in a
+ @Configuration class you can use
+ @ImportResource to import XML
+ configuration files. Note that this behavior is semantically
+ equivalent to how you configure your application in production: in
+ production configuration you will define either a set of XML
+ resource locations or a set of
+ @Configuration classes that your
+ production ApplicationContext will
+ load, but you still have the freedom to include or import the other
+ type of configuration.
+
+
Context configuration inheritance