From dc95e49c275b60d590885d1a6478f3aadf27fc60 Mon Sep 17 00:00:00 2001 From: Sam Brannen Date: Tue, 11 Oct 2011 23:20:50 +0000 Subject: [PATCH] [SPR-8240][SPR-8401] formatting and polishing. --- spring-framework-reference/src/testing.xml | 95 +++++++++++++--------- 1 file changed, 56 insertions(+), 39 deletions(-) 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.