diff --git a/spring-framework-reference/src/testing.xml b/spring-framework-reference/src/testing.xml
index dd29d5045da..aac9ec8a7d5 100644
--- a/spring-framework-reference/src/testing.xml
+++ b/spring-framework-reference/src/testing.xml
@@ -165,8 +165,8 @@
The Spring Framework provides first class support for integration
- testing in the form of the classes that are packaged in the spring-test.jar library. In this library,
+ testing in the org.springframework.test-VERSION.jar
+ library (where VERSION is the release version). In this library,
you will find the org.springframework.test package
which contains valuable classes for integration testing using a Spring
container, while at the same time not being reliant on an application
@@ -174,40 +174,35 @@
than unit tests but much faster to run than the equivalent Cactus tests
or remote tests relying on deployment to an application server.
- Prior to the 2.5 release of the framework, Spring provided integration testing support specific to
- JUnit 3.8. As of the 2.5 release, Spring offers support for unit
- and integration testing in the form of the Spring TestContext Framework,
- which is agnostic of the actual testing framework in use, thus allowing
- instrumentation of tests in various environments including JUnit 3.8,
- JUnit 4.5, TestNG, etc. Note that the Spring TestContext
- Framework requires Java 5+.
+
+ Since Spring 2.5 unit and integration testing support is provided
+ in the form of the annotation-driven Spring TestContext Framework.
+ The TestContext Framework is agnostic of the actual testing framework
+ in use, thus allowing
+ instrumentation of tests in various environments including JUnit 3.8,
+ JUnit 4.5, TestNG, etc.
+
+
+
+ Legacy JUnit 3.8 class hierarchy is deprecated
+
+ As of Spring 3.0, the legacy JUnit 3.8 base class hierarchy (e.g.,
+ AbstractDependencyInjectionSpringContextTests,
+ AbstractTransactionalDataSourceSpringContextTests,
+ etc.) is officially deprecated and will be removed in a later release.
+ Thus any code which depends on the legacy JUnit 3.8 support should be
+ migrated to the Spring TestContext Framework.
+
+
-
- Which support framework to use
-
- The Spring team recommends using the Spring TestContext Framework for
- all new unit testing or integration testing involving
- ApplicationContexts or requiring transactional
- test fixtures; however, if you are developing in a pre-Java 5
- environment, you will need to continue to use the JUnit 3.8 legacy support. In
- addition, explicit integration
- testing support for JPA which relies on shadow class
- loading for JPA class instrumentation is currently only
- available with the JUnit 3.8 legacy support. If you are testing against
- a JPA provider which does not require class instrumentation, however, it
- is recommended that you use the TestContext framework.
-
-
-
- Common goals
+
+ Goals
- The Spring integration testing support frameworks share several
- common goals, including:
+ The following bullet points highlight the fundamental goals of Spring's
+ integration testing support:
@@ -232,14 +227,15 @@
- The following sections outline each of these goals and provide
- direct links to information specific to the particular support
- frameworks.
+ In the next few sections each of the above goals is discussed
+ in greater detail, and at the end of each section you will find a direct
+ link to implementation and configuration details pertaining to that
+ particular goal.Context management and caching
- Spring integration testing support frameworks provide consistent
+ The Spring TestContext Framework provides consistent
loading of Spring ApplicationContexts and
caching of those contexts. Support for the caching of loaded contexts
is important, because if you are working on a large project, startup
@@ -251,7 +247,7 @@
test in every single test fixture will lead to slower overall test
runs that could reduce productivity.
- Test classes will generally provide an array containing the
+ Test classes provide an array containing the
resource locations of XML configuration metadata - typically on the
classpath - used to configure the application. This will be the same,
or nearly the same, as the list of configuration locations specified
@@ -265,29 +261,20 @@
unlikely case that a test may 'dirty' the application context,
requiring reloading - for example, by changing a bean definition or
the state of an application object - Spring's testing support provides
- mechanisms to cause the test fixture to reload the configurations and
+ a mechanism to cause the test fixture to reload the configurations and
rebuild the application context before executing the next test.
- Context management and caching with:
-
-
-
- JUnit 3.8
- legacy support
-
-
-
- The TestContext
- Framework
-
-
+
+ Context management and caching with the
+ TestContext Framework.
+ Dependency Injection of test fixtures
- When Spring integration testing support frameworks load your
- application context, they can optionally configure instances of your
+ When the TestContext framework loads your
+ application context, it can optionally configure instances of your
test classes via Dependency Injection. This provides a convenient
mechanism for setting up test fixtures using pre-configured beans from
your application context. A strong benefit here is that you can reuse
@@ -324,19 +311,10 @@
- Dependency Injection of test fixtures with:
-
-
-
- JUnit 3.8 legacy
- support
-
-
-
- The TestContext
- Framework
-
-
+
+ Dependency Injection of test fixtures with the
+ TestContext Framework.
+
@@ -348,8 +326,8 @@
Also, many operations - such as inserting to or modifying persistent
data - cannot be performed (or verified) outside a transaction.
- The Spring integration testing support frameworks meet this
- need. By default, they create and roll back a transaction for each
+ The TestContext framework meets this need. By default, the
+ 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
@@ -363,30 +341,21 @@
If you want a transaction to commit - unusual, but occasionally
useful when you want a particular test to populate or modify the
- database - the Spring integration testing support frameworks can be
+ database - the TestContext framework can be
instructed to cause the transaction to commit instead of roll back
- either by calling an inherited hook-method or by declaring a specific
- annotation.
-
- Transaction management with:
-
-
-
- JUnit 3.8 legacy
- support
-
+ via the @TransactionConfiguration
+ and @Rollback annotations.
-
- The TestContext
- Framework
-
-
+
+ Transaction management with the
+ TestContext Framework.
+ Integration testing support classes
- The Spring integration testing support frameworks provide
+ The Spring TestContext Framework provides
several abstract support classes that can simplify
writing integration tests. These base test classes provide well
defined hooks into the testing framework as well as convenient
@@ -401,8 +370,7 @@
- A JdbcTemplate or
- SimpleJdbcTemplate: useful for querying to
+ A SimpleJdbcTemplate: useful for querying to
confirm state. For example, you might query before and after
testing application code that creates an object and persists it
using an ORM tool, to verify that the data appears in the
@@ -414,23 +382,14 @@
- Often you will provide an application-wide superclass for
- integration tests that provides further useful instance variables used
- in many tests.
+ You may find it desirable to provide a custom, application-wide superclass for
+ integration tests that provides further useful instance variables and
+ methods specific to your project.
- Support classes for:
-
-
-
- JUnit 3.8
- legacy support
-
-
-
- The TestContext
- Framework
-
-
+
+ Support classes for the
+ TestContext Framework.
+
@@ -450,62 +409,43 @@
SimpleJdbcTestUtils internally.
-
- Common annotations
+
+ Annotations
- The Spring Framework provides a common set of
- Spring-specific annotations in the
- org.springframework.test.annotation package that you
- can use in your testing if you are developing against Java 5 or
- greater.
-
-
-
- @IfProfileValue
+
- Indicates that the annotated test is enabled for a specific
- testing environment. If the configured
- ProfileValueSource returns a matching
- value for the provided name,
- the test will be enabled. This annotation can be applied to an
- entire class or individual methods.
+ The Spring Framework provides the following set of
+ Spring-specific annotations that you
+ can use in your unit and integration tests in conjunction with the
+ TestContext framework. Refer to the respective JavaDoc for
+ further information, including default attribute values, etc.
- @IfProfileValue(name="java.vendor", value="Sun Microsystems Inc.")
-public void testProcessWhichRunsOnlyOnSunJvm() {
- // some logic that should run only on Java VMs from Sun Microsystems
-}
+
- Alternatively @IfProfileValue
- may be configured with a list of values (with
- OR semantics) to achieve TestNG-like support
- for test groups in a JUnit environment.
- Consider the following example:
+
+ @ContextConfiguration
- @IfProfileValue(name="test-groups", values={"unit-tests", "integration-tests"})
-public void testProcessWhichRunsForUnitOrIntegrationTestGroups() {
- // some logic that should run only for unit and integration test groups
-}
-
+ Defines class-level metadata which 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.
-
- @ProfileValueSourceConfiguration
-
- Class-level annotation which is used to specify what type of
- ProfileValueSource to use when retrieving
- profile values configured via the
- @IfProfileValue annotation. If
- @ProfileValueSourceConfiguration is
- not declared for a test,
- SystemProfileValueSource will be used by
- default.
-
- @ProfileValueSourceConfiguration(CustomProfileValueSource.class)
-public class CustomProfileValueSourceTests {
+ @ContextConfiguration(locations={"example/test-context.xml"}, loader=CustomContextLoader.class)
+public class CustomConfiguredApplicationContextTests {
// class body...
}
-
+
+ Note: @ContextConfiguration
+ provides support for inherited resource
+ locations by default. See the Context management and
+ caching section and JavaDoc for an example and further
+ details.
+ // some logic that results in the Spring container being dirtied
}
+
+ @TestExecutionListeners
-
- @ExpectedException
-
- Indicates that the annotated test method is expected to throw
- an exception during execution. The type of the expected exception is
- provided in the annotation, and if an instance of the exception is
- thrown during the test method execution then the test passes.
- Likewise if an instance of the exception is not
- thrown during the test method execution then the test fails.
-
- @ExpectedException(SomeBusinessException.class)
-public void testProcessRainyDayScenario() {
- // some logic that should result in an Exception being thrown
-}
-
-
-
- @Timed
-
- Indicates that the annotated test method has to finish
- execution in a specified time period (in milliseconds). If the text
- execution time takes longer than the specified time period, the test
- fails.
-
- Note that the time period includes execution of the test
- method itself, any repetitions of the test (see
- @Repeat), as well as any
- set up or tear down of the
- test fixture.
+ Defines class-level metadata for configuring which
+ TestExecutionListeners should be
+ registered with a TestContextManager.
+ Typically, @TestExecutionListeners
+ will be used in conjunction with
+ @ContextConfiguration.
- @Timed(millis=1000)
-public void testProcessWithOneSecondTimeout() {
- // some logic that should not take longer than 1 second to execute
+ @ContextConfiguration
+@TestExecutionListeners({CustomTestExecutionListener.class, AnotherTestExecutionListener.class})
+public class CustomTestExecutionListenerTests {
+ // class body...
}
-
-
- @Repeat
+ Note: @TestExecutionListeners
+ provides support for inherited listeners by
+ default. See the JavaDoc for an example and further
+ details.
+
- Indicates that the annotated test method must be executed
- repeatedly. The number of times that the test method is to be
- executed is specified in the annotation.
+
+ @TransactionConfiguration
- Note that the scope of execution to be repeated includes
- execution of the test method itself as well as any set
- up or tear down of the test
- fixture.
+ Defines class-level metadata for configuring transactional
+ tests. Specifically, the bean name of the
+ PlatformTransactionManager that is
+ to be used to drive transactions can be explicitly configured if
+ the bean name of the desired PlatformTransactionManager is not
+ "transactionManager". In addition, the
+ defaultRollback flag can optionally be changed
+ to false. Typically,
+ @TransactionConfiguration will be
+ used in conjunction with
+ @ContextConfiguration.
- @Repeat(10)
-public void testProcessRepeatedly() {
- // ...
+ @ContextConfiguration
+@TransactionConfiguration(transactionManager="txMgr", defaultRollback=false)
+public class CustomConfiguredTransactionalTests {
+ // class body...
}
-
+
+
+ @BeforeTransaction
+
+ Indicates that the annotated public void
+ method should be executed before a
+ transaction is started for test methods configured to run within a
+ transaction via the @Transactional
+ annotation.
+
+ @BeforeTransaction
+public void beforeTransaction() {
+ // logic to be executed before a transaction is started
+}
+
+
+
+ @AfterTransaction
+
+ Indicates that the annotated public void
+ method should be executed after a transaction
+ has been ended for test methods configured to run within a
+ transaction via the @Transactional
+ annotation.
+
+ @AfterTransaction
+public void afterTransaction() {
+ // logic to be executed after a transaction has ended
+}
+
+
@NotTransactional
@@ -610,353 +570,196 @@ public void testProcessWithoutTransaction() {
// ...
}
-
-
- Annotation support for:
-
-
-
- JUnit 3.8 legacy
- support: all common annotations listed above are supported
- but must be used in conjunction with
- AbstractAnnotationAwareTransactionalTests in
- order for the presence of these annotations to have any
- effect.
-
-
-
- The TestContext
- Framework: supports all of the common annotations listed
- above while providing additional TestContext-specific and
- transactional annotations (e.g.,
- @ContextConfiguration,
- @BeforeTransaction, etc.). Note,
- however, that some of the common annotations are only supported when
- used in conjunction with JUnit (e.g., with the SpringJUnit4ClassRunner
- or the JUnit
- 3.8 and JUnit 4.5 base
- test classes). Refer to the documentation in the
- TestContext Framework section for further
- details.
-
-
-
-
-
- JUnit 3.8 legacy support
-
- Spring's JUnit 3.8 legacy support consists of the classes
- found in the org.springframework.test package. This
- package provides valuable JUnit TestCase
- superclasses which can be extended for out-of-container integration
- tests involving Spring ApplicationContexts or
- requiring transactional support at the test method level.
-
-
- Context management and caching
-
- AbstractSingleSpringContextTests provides
- context management and caching support for JUnit 3.8 based test cases
- and exposes a protected method that subclasses can
- override to provide the location of context definition files:
-
- protected String[] getConfigLocations()
-
- Implementations of this method must provide an array containing
- the resource locations of XML configuration metadata - typically on
- the classpath - used to configure the application. This will be the
- same, or nearly the same, as the list of configuration locations
- specified in web.xml or other deployment
- configuration. As an alternative you may choose to override one of the
- following. See the respective JavaDoc for further details.
-
- protected String[] getConfigPaths()
-
- protected String getConfigPath()
-
- By default, once loaded, the configuration file set will be
- reused for each test case. Thus the setup cost will be incurred only
- once (per test fixture), and subsequent test execution will be much
- faster. In the unlikely case that a test may 'dirty' the application
- context, requiring reloading - for example, by changing a bean
- definition or the state of an application object - you can call the
- setDirty() method on
- AbstractSingleSpringContextTests to cause the
- test fixture to reload the configurations and rebuild the application
- context before executing the next test case. As an alternative, if you
- are developing against Java 5 or greater and extending AbstractAnnotationAwareTransactionalTests,
- you may annotate your test method with
- @DirtiesContext to achieve the same
- effect.
-
-
-
- Dependency Injection of test fixtures
-
- When
- AbstractDependencyInjectionSpringContextTests
- (and subclasses) load your application context, they can optionally
- configure instances of your test classes by Setter Injection. All you
- need to do is to define instance variables and the corresponding
- setter methods.
- AbstractDependencyInjectionSpringContextTests
- will automatically locate the corresponding object in the set of
- configuration files specified in the
- getConfigLocations() method.
-
- Consider the scenario where we have a class,
- HibernateTitleDao (as outlined in the Common goals section). Let's look
- at a JUnit 3.8 based implementation of the test class itself (we will
- look at the configuration immediately afterwards).
-
- public final class HibernateTitleDaoTests extends AbstractDependencyInjectionSpringContextTests {
-
- // this instance will be (automatically) dependency injected
- private HibernateTitleDao titleDao;
- // a setter method to enable DI of the 'titleDao' instance variable
- public void setTitleDao(HibernateTitleDao titleDao) {
- this.titleDao = titleDao;
- }
+
- public void testLoadTitle() throws Exception {
- Title title = this.titleDao.loadTitle(new Long(10));
- assertNotNull(title);
- }
+
- // specifies the Spring configuration to load for this test fixture
- protected String[] getConfigLocations() {
- return new String[] { "classpath:com/foo/daos.xml" };
- }
+ The following annotations are only
+ supported when used in conjunction with JUnit (i.e., with the SpringJUnit4ClassRunner or
+ the JUnit
+ 3.8 and JUnit 4.5 support
+ classes.
+
+
+ @IfProfileValue
+
+ Indicates that the annotated test is enabled for a specific
+ testing environment. If the configured
+ ProfileValueSource returns a matching
+ value for the provided name,
+ the test will be enabled. This annotation can be applied to an
+ entire class or individual methods.
+
+ @IfProfileValue(name="java.vendor", value="Sun Microsystems Inc.")
+public void testProcessWhichRunsOnlyOnSunJvm() {
+ // some logic that should run only on Java VMs from Sun Microsystems
+}
+
+ Alternatively @IfProfileValue
+ may be configured with a list of values (with
+ OR semantics) to achieve TestNG-like support
+ for test groups in a JUnit environment.
+ Consider the following example:
+
+ @IfProfileValue(name="test-groups", values={"unit-tests", "integration-tests"})
+public void testProcessWhichRunsForUnitOrIntegrationTestGroups() {
+ // some logic that should run only for unit and integration test groups
+}
+
+
+
+ @ProfileValueSourceConfiguration
+
+ Class-level annotation which is used to specify what type of
+ ProfileValueSource to use when retrieving
+ profile values configured via the
+ @IfProfileValue annotation. If
+ @ProfileValueSourceConfiguration is
+ not declared for a test,
+ SystemProfileValueSource will be used by
+ default.
+
+ @ProfileValueSourceConfiguration(CustomProfileValueSource.class)
+public class CustomProfileValueSourceTests {
+ // class body...
+}
+
+
+
+ @ExpectedException
+
+ Indicates that the annotated test method is expected to throw
+ an exception during execution. The type of the expected exception is
+ provided in the annotation, and if an instance of the exception is
+ thrown during the test method execution then the test passes.
+ Likewise if an instance of the exception is not
+ thrown during the test method execution then the test fails.
+
+ @ExpectedException(SomeBusinessException.class)
+public void testProcessRainyDayScenario() {
+ // some logic that should result in an Exception being thrown
}
- The file referenced by the
- getConfigLocations() method (i.e.,
- "classpath:com/foo/daos.xml") looks like
- this:
-
- <?xml version="1.0" encoding="UTF-8"?>
-<beans xmlns="http://www.springframework.org/schema/beans"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://www.springframework.org/schema/beans
- http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
-
- <!-- this bean will be injected into the HibernateTitleDaoTests class -->
- <bean id="titleDao" class="com.foo.dao.hibernate.HibernateTitleDao">
- <property name="sessionFactory" ref="sessionFactory"/>
- </bean>
-
- <bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
- <!-- dependencies elided for clarity -->
- </bean>
-
-</beans>
-
- The
- AbstractDependencyInjectionSpringContextTests
- classes uses autowire
- by type. Thus if you have multiple bean definitions
- of the same type, you cannot rely on this approach for those
- particular beans. In that case, you can use the inherited
- applicationContext instance variable and perform
- explicit lookups using (for example) a call to
- applicationContext.getBean("titleDao").
-
- If you don't want dependency injection applied to your test
- cases, simply don't declare any public setter
- methods. Alternatively, you can extend
- AbstractSpringContextTests - the root of the
- JUnit 3.8 integration testing support class hierarchy in the
- org.springframework.test package - which merely
- contains convenience methods to load Spring contexts and performs no
- Dependency Injection of the test fixture.
-
-
- Field level injection
-
- If, for whatever reason, you don't fancy having setter methods
- in your test fixtures, Spring can inject dependencies into
- protected fields. Find below a reworking of the
- previous example to use field level injection (the Spring XML
- configuration does not need to change, merely the test
- fixture).
-
- public final class HibernateTitleDaoTests extends AbstractDependencyInjectionSpringContextTests {
-
- public HibernateTitleDaoTests() {
- // switch on field level injection
- setPopulateProtectedVariables(true);
- }
-
- // this instance will be (automatically) dependency injected
- protected HibernateTitleDao titleDao;
-
- public void testLoadTitle() throws Exception {
- Title title = this.titleDao.loadTitle(new Long(10));
- assertNotNull(title);
- }
-
- // specifies the Spring configuration to load for this test fixture
- protected String[] getConfigLocations() {
- return new String[] { "classpath:com/foo/daos.xml" };
- }
+ Using Spring's
+ @ExpectedException annotation in
+ conjunction with JUnit 4's
+ @Test(expected=...) configuration
+ would lead to an unresolvable conflict. Developers must therefore
+ choose one or the other when integrating with JUnit 4, in which
+ case it is generally preferable to use the explicit JUnit 4
+ configuration.
+
+
+ @Timed
+
+ Indicates that the annotated test method has to finish
+ execution in a specified time period (in milliseconds). If the text
+ execution time takes longer than the specified time period, the test
+ fails.
+
+ Note that the time period includes execution of the test
+ method itself, any repetitions of the test (see
+ @Repeat), as well as any
+ set up or tear down of the
+ test fixture.
+
+ @Timed(millis=1000)
+public void testProcessWithOneSecondTimeout() {
+ // some logic that should not take longer than 1 second to execute
}
- In the case of field injection, there is no autowiring going
- on: the name of a protected instance variable is
- used as the lookup bean name in the configured Spring
- container.
-
-
+ Spring's @Timed annotation
+ has different semantics than JUnit 4's
+ @Test(timeout=...) support.
+ Specifically, due to the manner in which JUnit 4 handles test
+ execution timeouts (i.e., by executing the test method in a
+ separate Thread),
+ @Test(timeout=...) applies to
+ each iteration in the case of repetitions
+ and preemptively fails the test if the test takes too long.
+ Spring's @Timed, on the other hand,
+ times the total test execution time
+ (including all repetitions) and does not preemptively fail the test
+ but rather waits for the test to actually complete before failing.
+
-
- Transaction management
+
+ @Repeat
+
+ Indicates that the annotated test method must be executed
+ repeatedly. The number of times that the test method is to be
+ executed is specified in the annotation.
+
+ Note that the scope of execution to be repeated includes
+ execution of the test method itself as well as any set
+ up or tear down of the test
+ fixture.
+
+ @Repeat(10)
+public void testProcessRepeatedly() {
+ // ...
+}
+
- AbstractTransactionalSpringContextTests
- depends on a PlatformTransactionManager bean
- being defined in the application context. The name doesn't matter due
- to the use of autowire by
- type.
-
- Typically you will extend the subclass,
- AbstractTransactionalDataSourceSpringContextTests.
- This class also requires that a DataSource bean
- definition - again, with any name - be present in the application
- context. It creates a JdbcTemplate instance
- variable, that is useful for convenient querying, and provides handy
- methods to delete the contents of selected tables (remember that the
- transaction will roll back by default, so this is safe to do).
-
- If you want a transaction to commit
- programmatically - unusual, but occasionally
- useful when you want a particular test to populate the database - you
- can call the setComplete() method inherited
- from AbstractTransactionalSpringContextTests.
- This will cause the transaction to commit instead of roll back. As an
- alternative, if you are developing against Java 5 or greater and
- extending AbstractAnnotationAwareTransactionalTests,
- you may annotate your test method with
- @Rollback(false) to achieve the same
- effect through configuration.
-
- There is also the convenient ability to end a transaction before
- the test case ends, by calling the
- endTransaction() method. This will roll back
- the transaction by default and commit it only if
- setComplete() had previously been called.
- This functionality is useful if you want to test the behavior of
- 'disconnected' data objects, such as Hibernate-mapped entities that
- will be used in a web or remoting tier outside a transaction. Often,
- lazy loading errors are discovered only through UI testing; if you
- call endTransaction() you can ensure correct
- operation of the UI through your JUnit test suite.
-
+
-
- JUnit 3.8 legacy support classes
+
- When you extend the
- AbstractTransactionalDataSourceSpringContextTests
- class you will have access to the following
- protected instance variables:
+
+ The following non-test-specific annotations are supported with
+ standard semantics for all
+ configurations of the Spring TestContext Framework.
+
- applicationContext (a
- ConfigurableApplicationContext):
- inherited from the
- AbstractSingleSpringContextTests
- superclass. Use this to perform explicit bean lookup or to test
- the state of the context as a whole.
+ @Autowired
- jdbcTemplate: inherited from
- AbstractTransactionalDataSourceSpringContextTests.
- Useful for querying to confirm state. For example, you might query
- before and after testing application code that creates an object
- and persists it using an ORM tool, to verify that the data appears
- in the database. (Spring will ensure that the query runs in the
- scope of the same transaction.) You will need to tell your ORM
- tool to 'flush' its changes for this to work correctly, for
- example using the flush() method on
- Hibernate's Session interface.
+ @Qualifier
-
-
-
-
- Java 5+ specific support
-
-
- Annotation aware transactional tests
-
- In addition to the aforementioned common
- annotations, the
- org.springframework.test.annotation package also
- contains an abstract JUnit
- TestCase class which provides
- annotation-driven integration testing support.
- The
- AbstractAnnotationAwareTransactionalTests
- class extends
- AbstractTransactionalDataSourceSpringContextTests
- and makes text fixtures, which extend it, aware of a number of
- (Spring-specific) annotations.
- AbstractAnnotationAwareTransactionalTests
- supports all annotations listed in the common
- annotations section as well as Spring's
- @Transactional annotation for
- configuring explicit transactional semantics.
-
+
+ @Resource (javax.annotation)
+ if JSR-250 is present
+
-
- JPA support classes
+
+ @PersistenceContext
+ (javax.persistence) if JPA is present
+
- The org.springframework.test.jpa package
- provides support classes for tests based on the Java Persistence API
- (JPA).
+
+ @PersistenceUnit
+ (javax.persistence) if JPA is present
+
-
-
- AbstractJpaTests is a convenient
- support class for JPA-related tests, which offers the same
- contract as
- AbstractTransactionalDataSourceSpringContextTests
- and equally good performance, even when performing the
- instrumentation required by the JPA specification. Exposes an
- EntityManagerFactory and a shared
- EntityManager. Requires an
- EntityManagerFactory to be
- injected, plus the DataSource and
- JpaTransactionManager through the
- superclass.
-
+
+ @Required
+
-
- AbstractAspectjJpaTests is a
- subclass of AbstractJpaTests that
- activates AspectJ load-time weaving and allows the ability to
- specify a custom location for AspectJ's
- aop.xml file.
-
-
-
-
+
+ @Transactional
+
+
@@ -983,12 +786,12 @@ public void testProcessWithoutTransaction() {
The following section provides an overview of the internals of the
TestContext framework. If you are only interested in using the framework
and not necessarily interested in extending it with your own custom
- listeners, feel free to skip ahead to the configuration (context management, dependency injection, transaction management), support classes, and annotation support
+ linkend="integration-testing-annotations">annotation support
sections.
@@ -1098,8 +901,8 @@ public class MyTest {
}
- In contrast to the JUnit 3.8 legacy support, test classes which
- use the TestContext framework do not need to override any
+ In contrast to the now deprecated JUnit 3.8 legacy support, test
+ classes which use the TestContext framework do not need to override any
protected instance methods to configure their
application context. Rather, configuration is achieved merely by
declaring the @ContextConfiguration
@@ -1146,7 +949,14 @@ public class MyTest {
// class body...
}
- @ContextConfiguration also
+ @ContextConfiguration supports
+ an alias for the locations attribute via the
+ standard value attribute. Thus, if you do not need
+ to configure a custom ContextLoader, you
+ can omit the declaration of the locations attribute
+ name and declare the resource locations using the shorthand format
+ demonstrated in the following example.
+ @ContextConfiguration also
supports a boolean inheritLocations attribute which
denotes whether or not resource locations from superclasses should be
inherited. The default value is
@@ -1166,14 +976,14 @@ public class MyTest {
@RunWith(SpringJUnit4ClassRunner.class)
// ApplicationContext will be loaded from "/base-context.xml" in the root of the classpath
-@ContextConfiguration(locations={"/base-context.xml"})
+@ContextConfiguration("/base-context.xml")
public class BaseTest {
// class body...
}
// ApplicationContext will be loaded from "/base-context.xml" and "/extended-context.xml"// in the root of the classpath
-@ContextConfiguration(locations={"/extended-context.xml"})
+@ContextConfiguration("/extended-context.xml")
public class ExtendedTest extends BaseTest {
// class body...
}
@@ -1258,7 +1068,7 @@ public class ExtendedTest extends BaseTest {
Consider the scenario where we have a class,
HibernateTitleDao (as outlined in the common goals section). First,
+ linkend="testing-fixture-di">Goals section). First,
let's look at a JUnit 4.5 based implementation of the test class
itself which uses @Autowired for field
injection (we will look at the application context configuration after
@@ -1442,8 +1252,8 @@ public final class HibernateTitleDaoTests {
For class-level transaction configuration (i.e., setting the
bean name for the transaction manager and the default rollback flag),
see the @TransactionConfiguration entry
- in the TestContext framework
- annotation support section.
+ in the annotation support
+ section.There are several options for configuring transactions for
individual test methods. If transactions are not enabled for the
@@ -1497,7 +1307,7 @@ public final class HibernateTitleDaoTests {
The following JUnit 4 based example displays a fictitious
integration testing scenario highlighting several of the
transaction-related annotations. Consult the TestContext framework annotation
+ linkend="integration-testing-annotations">annotation
support section of the reference manual for further information
and configuration examples.
@@ -1815,218 +1625,6 @@ public class SimpleTest {
-
- TestContext framework annotation support
-
-
-
- The Spring TestContext Framework supports all annotations as
- outlined in the common
- annotations section. The following annotations, however, are
- only supported when used in conjunction with JUnit (e.g.,
- with the SpringJUnit4ClassRunner or
- the JUnit
- 3.8 and JUnit 4.5 support
- classes.
-
-
-
- @IfProfileValue
-
-
-
- @ProfileValueSourceConfiguration
-
-
-
- @ExpectedException
-
- Using Spring's
- @ExpectedException annotation in
- conjunction with JUnit 4's
- @Test(expected=...) configuration
- would lead to an unresolvable conflict. Developers must therefore
- choose one or the other when integrating with JUnit 4, in which
- case it is generally preferable to use the explicit JUnit 4
- configuration.
-
-
-
- @Timed
-
- Spring's @Timed annotation
- has different semantics than JUnit 4's
- @Test(timeout=...) support.
- Specifically, due to the manner in which JUnit 4 handles test
- execution timeouts (i.e., by executing the test method in a
- separate Thread),
- @Test(timeout=...) applies to
- each iteration in the case of repetitions
- and preemptively fails the test if the test takes too long.
- Spring's @Timed, on the other hand,
- times the total test execution time
- (including all repetitions) and does not preemptively fail the test
- but rather waits for the test to actually complete before failing.
-
-
-
- @Repeat
-
-
-
-
-
- The following non-test-specific annotations are also supported
- by the Spring TestContext Framework with their standard
- semantics.
-
-
-
- @Autowired
-
-
-
- @Qualifier
-
-
-
- @Resource (javax.annotation)
- if JSR-250 is present
-
-
-
- @PersistenceContext
- (javax.persistence) if JPA is present
-
-
-
- @PersistenceUnit
- (javax.persistence) if JPA is present
-
-
-
- @Required
-
-
-
- @Transactional
-
-
-
-
-
- The following list includes all annotations specific to the
- Spring TestContext Framework. Refer to the respective JavaDoc for
- further information, including default attribute values, etc.
-
-
-
- @ContextConfiguration
-
- Defines class-level metadata which 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.
-
- @ContextConfiguration(locations={"example/test-context.xml"}, loader=CustomContextLoader.class)
-public class CustomConfiguredApplicationContextTests {
- // class body...
-}
-
- Note: @ContextConfiguration
- provides support for inherited resource
- locations by default. See the Context management and
- caching section and JavaDoc for an example and further
- details.
-
-
-
- @TestExecutionListeners
-
- Defines class-level metadata for configuring which
- TestExecutionListeners should be
- registered with a TestContextManager.
- Typically, @TestExecutionListeners
- will be used in conjunction with
- @ContextConfiguration.
-
- @ContextConfiguration
-@TestExecutionListeners({CustomTestExecutionListener.class, AnotherTestExecutionListener.class})
-public class CustomTestExecutionListenerTests {
- // class body...
-}
-
- Note: @TestExecutionListeners
- provides support for inherited listeners by
- default. See the JavaDoc for an example and further
- details.
-
-
-
- @TransactionConfiguration
-
- Defines class-level metadata for configuring transactional
- tests. Specifically, the bean name of the
- PlatformTransactionManager that is
- to be used to drive transactions can be explicitly configured if
- the bean name of the desired PlatformTransactionManager is not
- "transactionManager". In addition, the
- defaultRollback flag can optionally be changed
- to false. Typically,
- @TransactionConfiguration will be
- used in conjunction with
- @ContextConfiguration.
-
- @ContextConfiguration
-@TransactionConfiguration(transactionManager="txMgr", defaultRollback=false)
-public class CustomConfiguredTransactionalTests {
- // class body...
-}
-
-
-
- @BeforeTransaction
-
- Indicates that the annotated public void
- method should be executed before a
- transaction is started for test methods configured to run within a
- transaction via the @Transactional
- annotation.
-
- @BeforeTransaction
-public void beforeTransaction() {
- // logic to be executed before a transaction is started
-}
-
-
-
- @AfterTransaction
-
- Indicates that the annotated public void
- method should be executed after a transaction
- has been ended for test methods configured to run within a
- transaction via the @Transactional
- annotation.
-
- @AfterTransaction
-public void afterTransaction() {
- // logic to be executed after a transaction has ended
-}
-
-
-