diff --git a/spring-framework-reference/src/testing.xml b/spring-framework-reference/src/testing.xml
index 6c827acfc6..b8f8db578a 100644
--- a/spring-framework-reference/src/testing.xml
+++ b/spring-framework-reference/src/testing.xml
@@ -1283,7 +1283,7 @@ public class OrderServiceTest {
production configuration you will define either a set of XML
resource locations or a set of
@Configuration classes that your
- production ApplicationContext will
+ production ApplicationContext will be
loaded from, but you still have the freedom to include or import the
other type of configuration.
@@ -1362,22 +1362,26 @@ public class ExtendedTest extends BaseTest {
Context configuration with environment profiles
Spring 3.1 introduces first-class support in the framework for
- the notion of environments and profiles (a.k.a., bean definition
- profiles), and integration tests can now be configured to activate
- particular bean definition profiles for various testing scenarios.
- This is achieved by annotating a test class with the new
- @ActiveProfiles annotation and supplying a list of profiles that
- should be activated when loading the ApplicationContext for the
- test.
+ the notion of environments and profiles (a.k.a., bean
+ definition profiles), and integration tests can now be
+ configured to activate particular bean definition profiles for
+ various testing scenarios. This is achieved by annotating a test
+ class with the new @ActiveProfiles
+ annotation and supplying a list of profiles that should be activated
+ when loading the ApplicationContext
+ for the test.
- @ActiveProfiles may be used with any implementation of the
- new SmartContextLoader SPI, but @ActiveProfiles is not supported
- with implementations of the older ContextLoader SPI.
+ @ActiveProfiles may be used
+ with any implementation of the new
+ SmartContextLoader SPI, but
+ @ActiveProfiles is not supported
+ with implementations of the older
+ ContextLoader SPI.
Let's take a look at some examples with XML configuration and
- @Configuration classes.
+ @Configuration classes.
<!-- app-config.xml -->
<beans xmlns="http://www.springframework.org/schema/beans"
@@ -1433,25 +1437,33 @@ public class TransferServiceTest {
}
}
- When TransferServiceTest is run, its ApplicationContext will
- be loaded from the app-config.xml configuration file in the root of
- the classpath. If you inspect app-config.xml you'll notice that the
- accountRepository bean has a dependency on a dataSource bean;
- however, dataSource is not defined as a top-level bean. Instead,
- dataSource is defined twice: once in the production profile and once
- in the dev profile.
+ When TransferServiceTest is run, its
+ ApplicationContext will be loaded
+ from the app-config.xml configuration file in
+ the root of the classpath. If you inspect
+ app-config.xml you'll notice that the
+ accountRepository bean has a dependency on a
+ dataSource bean; however,
+ dataSource is not defined as a top-level bean.
+ Instead, dataSource is defined twice: once in the
+ production profile and once in the
+ dev profile.
- By annotating TransferServiceTest with @ActiveProfiles("dev")
- we instruct the Spring TestContext Framework to load the
- ApplicationContext with the active profiles set to {"dev"}. As a
- result, an embedded database will be created, and the
- accountRepository bean will be wired with a reference to the
- development DataSource. And that's likely what we want in an
- integration test.
+ By annotating TransferServiceTest with
+ @ActiveProfiles("dev") we instruct
+ the Spring TestContext Framework to load the
+ ApplicationContext with the active
+ profiles set to {"dev"}. As a result, an embedded
+ database will be created, and the
+ accountRepository bean will be wired with a
+ reference to the development
+ DataSource. And that's likely what we
+ want in an integration test.
The following code listings demonstrate how to implement the
- same configuration and integration test but using @Configuration
- classes instead of XML.
+ same configuration and integration test but using
+ @Configuration classes instead of
+ XML.
@Configuration
@Profile("dev")
@@ -1510,30 +1522,35 @@ public class TransferServiceTest {
}
In this variation, we have split the XML configuration into
- three independent @Configuration classes:
+ three independent @Configuration
+ classes:
- TransferServiceConfig: acquires a dataSource via
- dependency injection using @Autowired
+ TransferServiceConfig: acquires a
+ dataSource via dependency injection using
+ @Autowired
- StandaloneDataConfig: defines a dataSource for an embedded
- database suitable for developer tests
+ StandaloneDataConfig: defines a
+ dataSource for an embedded database suitable
+ for developer tests
- JndiDataConfig: defines a dataSource that is retrieved
- from JNDI in a production environment
+ JndiDataConfig: defines a
+ dataSource that is retrieved from JNDI in a
+ production environment
As with the XML-based configuration example, we still annotate
- TransferServiceTest with @ActiveProfiles("dev"), but this time we
- specify all three configuration classes via the
- @ContextConfiguration annotation. The body of the test class itself
- remains completely unchanged.
+ TransferServiceTest with
+ @ActiveProfiles("dev"), but this time
+ we specify all three configuration classes via the
+ @ContextConfiguration annotation. The
+ body of the test class itself remains completely unchanged.