From b6f99e38ae35a25034df0eb3e7750b1036ea8ddd Mon Sep 17 00:00:00 2001 From: Sam Brannen Date: Wed, 6 Apr 2016 14:45:28 +0200 Subject: [PATCH] Polish wording regarding previous release versions in reference manual --- src/asciidoc/testing.adoc | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/src/asciidoc/testing.adoc b/src/asciidoc/testing.adoc index 72c8f76810..4ee38a79dc 100644 --- a/src/asciidoc/testing.adoc +++ b/src/asciidoc/testing.adoc @@ -75,7 +75,7 @@ The `org.springframework.mock.web` package contains a comprehensive set of Servl mock objects, which are useful for testing web contexts, controllers, and filters. These mock objects are targeted at usage with Spring's Web MVC framework and are generally more convenient to use than dynamic mock objects such as http://www.easymock.org[EasyMock] or -alternative Servlet API mock objects such as http://www.mockobjects.com[MockObjects]. As of +alternative Servlet API mock objects such as http://www.mockobjects.com[MockObjects]. Since Spring Framework 4.0, the set of mocks in the `org.springframework.mock.web` package is based on the Servlet 3.0 API. @@ -1127,7 +1127,7 @@ well as any __set up__ or __tear down__ of the test fixture. [[integration-testing-annotations-meta]] ==== Meta-Annotation Support for Testing -As of Spring Framework 4.0, it is possible to use test-related annotations as +Since Spring Framework 4.0, it is possible to use test-related annotations as <> in order to create custom _composed annotations_ and reduce configuration duplication across a test suite. @@ -1347,8 +1347,8 @@ via the `@TestExecutionListeners` annotation. See Registering custom ++TestExecutionListener++s via `@TestExecutionListeners` is suitable for custom listeners that are used in limited testing scenarios; however, it can become -cumbersome if a custom listener needs to be used across a test suite. To address this -issue, Spring Framework 4.1 supports automatic discovery of _default_ +cumbersome if a custom listener needs to be used across a test suite. Since Spring +Framework 4.1, this issue is addressed via support for automatic discovery of _default_ `TestExecutionListener` implementations via the `SpringFactoriesLoader` mechanism. Specifically, the `spring-test` module declares all core default @@ -1401,7 +1401,8 @@ any custom listeners. The following listing demonstrates this style of configura The challenge with this approach is that it requires that the developer know exactly which listeners are registered by default. Moreover, the set of default listeners can change from release to release -- for example, `SqlScriptsTestExecutionListener` was -introduced in Spring Framework 4.1. Furthermore, third-party frameworks like Spring +introduced in Spring Framework 4.1, and `DirtiesContextBeforeModesTestExecutionListener` +was introduced in Spring Framework 4.2. Furthermore, third-party frameworks like Spring Security register their own default ++TestExecutionListener++s via the aforementioned <>. @@ -2548,6 +2549,7 @@ the context cache key: * `locations` __(from @ContextConfiguration)__ * `classes` __(from @ContextConfiguration)__ * `contextInitializerClasses` __(from @ContextConfiguration)__ +* `contextCustomizers` __(from ContextCustomizerFactory)__ * `contextLoader` __(from @ContextConfiguration)__ * `parent` __(from @ContextHierarchy)__ * `activeProfiles` __(from @ActiveProfiles)__ @@ -2617,7 +2619,7 @@ components. Another use case can be found in Spring Batch applications where you have a parent context that provides configuration for shared batch infrastructure and a child context for the configuration of a specific batch job. -As of Spring Framework 3.2.2, it is possible to write integration tests that use context +Since Spring Framework 3.2.2, it is possible to write integration tests that use context hierarchies by declaring context configuration via the `@ContextHierarchy` annotation, either on an individual test class or within a test class hierarchy. If a context hierarchy is declared on multiple classes within a test class hierarchy it is also @@ -2921,9 +2923,8 @@ bean by name there (as shown above, assuming that "myDataSource" is the bean id) ==== Testing request and session scoped beans <> have been supported by -Spring for several years now, but it's always been a bit non-trivial to test them. As of -Spring 3.2 it's a breeze to test your request-scoped and session-scoped beans by -following these steps. +Spring since the early years, and since Spring 3.2 it's a breeze to test your +request-scoped and session-scoped beans by following these steps. * Ensure that a `WebApplicationContext` is loaded for your test by annotating your test class with `@WebAppConfiguration`. @@ -3155,7 +3156,7 @@ via the `@Commit` and `@Rollback` annotations. See the corresponding entries in [[testcontext-tx-programmatic-tx-mgt]] ===== Programmatic transaction management -As of Spring Framework 4.1, it is possible to interact with test-managed transactions +Since Spring Framework 4.1, it is possible to interact with test-managed transactions _programmatically_ via the static methods in `TestTransaction`. For example, `TestTransaction` may be used within _test_ methods, _before_ methods, and _after_ methods to start or end the current test-managed transaction or to configure the current @@ -4119,7 +4120,7 @@ This can be done as follows, where `print()` is a static import from ---- As long as request processing does not cause an unhandled exception, the `print()` method -will print all the available result data to `System.out`. Spring Framework 4.2 introduces +will print all the available result data to `System.out`. Spring Framework 4.2 introduced a `log()` method and two additional variants of the `print()` method, one that accepts an `OutputStream` and one that accepts a `Writer`. For example, invoking `print(System.err)` will print the result data to `System.err`; while invoking