From 15f217c27475738c77523f200aa3c895d13d0ead Mon Sep 17 00:00:00 2001 From: Sam Brannen Date: Wed, 28 Sep 2011 22:28:29 +0000 Subject: [PATCH] [SPR-8240] Documenting TestContext support for @Configuration classes in the reference manual. --- spring-framework-reference/src/testing.xml | 78 ++++++++++++---------- 1 file changed, 42 insertions(+), 36 deletions(-) diff --git a/spring-framework-reference/src/testing.xml b/spring-framework-reference/src/testing.xml index f1d0e4111e4..171a5e1bbc1 100644 --- a/spring-framework-reference/src/testing.xml +++ b/spring-framework-reference/src/testing.xml @@ -9,10 +9,11 @@ Testing is an integral part of enterprise software development. This chapter focuses on the value-add of the IoC principle to unit testing and on the benefits of the Spring - Framework's support for integration - testing. (A thorough treatment of testing in the enterprise - is beyond the scope of this reference manual.) + linkend="unit-testing">unit testing and on the benefits of the + Spring Framework's support for integration testing. (A + thorough treatment of testing in the enterprise is beyond the scope of + this reference manual.)
@@ -252,24 +253,26 @@ every test fixture leads to slower overall test runs that could reduce productivity. - - - Test classes provide an array containing the resource locations - of XML configuration metadata — typically in the classpath — that is - used to configure the application. These locations are the same as or - similar to the list of configuration locations specified in + Test classes can provide either an array containing the resource + locations of XML configuration metadata — typically in the classpath — + or an array containing @Configuration + classes that is used to configure the application. These locations or + classes are the same as or similar to those specified in web.xml or other deployment configuration files. By default, once loaded, the configured ApplicationContext is reused for each test. Thus the setup cost is incurred only once (per test suite), and - subsequent test execution is much faster. In the unlikely case that a - test corrupts the application context and requires reloading — for - example, by modifying a bean definition or the state of an application - object — the TestContext framework can be configured to reload the - configuration and rebuild the application context before executing the - next test. + subsequent test execution is much faster. In this context, the term + test suite means all tests run in the same JVM — + for example, all tests run from an Ant or Maven build for a given + project or module. In the unlikely case that a test corrupts the + application context and requires reloading — for example, by modifying + a bean definition or the state of an application object — the + TestContext framework can be configured to reload the configuration + and rebuild the application context before executing the next + test. See context management and caching with the TestContext @@ -292,9 +295,8 @@ As an example, consider the scenario where we have a class, HibernateTitleRepository, that performs data - access logic for say, the Title domain object. - We want to write integration tests that test all of the following - areas: + access logic for a Title domain entity. We want + to write integration tests that test the following areas: @@ -334,13 +336,14 @@ framework will create and roll back a transaction for each test. You simply write code that can assume the existence of a transaction. If you call transactionally proxied objects in your tests, they will - behave correctly, according to their transactional semantics. In - addition, if test methods delete the contents of selected tables while - running within a transaction, the transaction will roll back by - default, and the database will return to its state prior to execution - of the test. Transactional support is provided to your test class via - a PlatformTransactionManager bean defined in - the test's application context. + behave correctly, according to their configured transactional + semantics. In addition, if test methods delete the contents of + selected tables while running within a transaction, the transaction + will roll back by default, and the database will return to its state + prior to execution of the test. Transactional support is provided to + your test class via a + PlatformTransactionManager bean defined in the + test's application context. If you want a transaction to commit — unusual, but occasionally useful when you want a particular test to populate or modify the @@ -399,8 +402,8 @@ The org.springframework.test.jdbc package contains SimpleJdbcTestUtils, which is a - Java-5-based collection of JDBC related utility functions intended to - simplify standard database testing scenarios. Note that Note that AbstractTransactionalJUnit4SpringContextTests and AbstractTransactionalTestNGSpringContextTests @@ -424,14 +427,17 @@ Defines class-level metadata that is used to determine how to load and configure an - ApplicationContext. Specifically, - @ContextConfiguration defines the - application context resource locations 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 - supports either resource locations or - configuration classes. + ApplicationContext for test classes. + Specifically, @ContextConfiguration + declares either the application context resource + locations or the + @Configuration + classes 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 supports + either resource locations or configuration + classes. @ContextConfiguration(locations="example/test-context.xml", loader=CustomContextLoader.class) public class CustomConfiguredApplicationContextTests {