The change removes the use of concrete Matcher implementations and thus
the dependency on hamcrest-lib leaving hamcrest-core as the only
(optional) hamcrest dependency.
Issue: SPR-9961
1) removed the hamcrest-all dependency requirement and replaced it with
the more focused hamcrest-library dependency
2) added MatcherAssertionErrors as a replacement of
org.hamcrest.MatcherAssert, which in hamcrest 1.1 is only available
through the hamcrest-all dependency (and not in hamcrest-core nor in
the hamcrest embedded in JUnit 4.4 through 4.8)
3) changed the required hamcrest version from 1.1 to 1.3 and made sure
the spring-test-mvc project does not rely on newer hamcrest
functionality without checking if it is available first
Applications that already depend on older versions of hamcrest
(in particular 1.1) via hamcrest-library, hamcrest-all or as part of
junit 4.4 through 4.8 should not be disrupted if they add spring-test
but may wish to exclude the hamcrest-library transitive dependency
from spring-test in order to avoid extra jars in the classpath
Applications that depend on hamcrest 1.3 should not have to do anything
Issue: SPR-9940
This commit validates the claims made in SPR-9799.
- Spr9799XmlConfigTests demonstrates that a WAC is not always necessary
when integration testing with XML configuration that uses
<mvc:annotation-driven />.
- Spr9799AnnotationConfigTests demonstrates that a WAC is in fact
necessary when integration testing with a configuration class that
uses @EnableWebMvc.
Issue: SPR-9799
New afterTimeout and afterCompletion callbacks
afterTimeout can provide a concurrent result to be used instead of the
one that could not be set or returned on time
Interceptor exceptions cause async processing to resume treating the
exception as the concurrent result
Adapter classes for convenient implementation of the interfaces
Issue: SPR-9914
When obtaining an async result, tests will now await concurrent
processing to complete for the exact amount of time equal to the
actual async timeout value.
Issue: SPR-9875
Remove use of UriTemplate in MockMvcRequestBuilders.
Rely on UriComponentsBuilder instead.
Decode query params before setting them on MockHttpServletRequest.
Add more options to model result matching for the count of errors.
Ignore white spaces and comments when comparing XML.
Add "MockRest-" prefix to RequestMatchers and ResponseCreators to
make it easy to find classes with static imports with
Ctrl+Shift+T "MockRest" - similar to the "MockMvc"
prefix on the server-side.
Prior to this commit, the Spring TestContext Framework only supported
loading an ApplicationContext in integration tests from either XML or
Java Properties files (since Spring 2.5), and Spring 3.1 introduced
support for loading an ApplicationContext in integration tests from
annotated classes (e.g., @Configuration classes). All of the
ContextLoader implementations used to provide this support load a
GenericApplicationContext. However, a GenericApplicationContext is not
suitable for testing a web application since a web application relies on
an implementation of WebApplicationContext (WAC).
This commit makes it possible to integration test Spring-powered web
applications by adding the following functionality to the Spring
TestContext Framework.
- Introduced AbstractGenericWebContextLoader and two concrete
subclasses:
- XmlWebContextLoader
- AnnotationConfigWebContextLoader
- Pulled up prepareContext(context, mergedConfig) from
AbstractGenericContextLoader into AbstractContextLoader to allow it
to be shared across web and non-web context loaders.
- Introduced AnnotationConfigContextLoaderUtils and refactored
AnnotationConfigContextLoader accordingly. These utils are also used
by AnnotationConfigWebContextLoader.
- Introduced a new @WebAppConfiguration annotation to denote that the
ApplicationContext loaded for a test should be a WAC and to configure
the base resource path for the root directory of a web application.
- Introduced WebMergedContextConfiguration which extends
MergedContextConfiguration with support for a baseResourcePath for
the root directory of a web application.
- ContextLoaderUtils.buildMergedContextConfiguration() now builds a
WebMergedContextConfiguration instead of a standard
MergedContextConfiguration if @WebAppConfiguration is present on the
test class.
- Introduced a configureWebResources() method in
AbstractGenericWebContextLoader that is responsible for creating a
MockServletContext with a proper ResourceLoader for the
resourceBasePath configured in the WebMergedContextConfiguration. The
resulting mock ServletContext is set in the WAC, and the WAC is
stored as the Root WAC in the ServletContext.
- Introduced a WebTestExecutionListener that sets up default thread
local state via RequestContextHolder before each test method by using
the MockServletContext already present in the WAC and by creating a
MockHttpServletRequest, MockHttpServletResponse, and
ServletWebRequest that is set in the RequestContextHolder. WTEL also
ensures that the MockHttpServletResponse and ServletWebRequest can be
injected into the test instance (e.g., via @Autowired) and cleans up
thread locals after each test method.
- WebTestExecutionListener is configured as a default
TestExecutionListener before DependencyInjectionTestExecutionListener
- Extracted AbstractDelegatingSmartContextLoader from
DelegatingSmartContextLoader and introduced a new
WebDelegatingSmartContextLoader.
- ContextLoaderUtils now selects the default delegating ContextLoader
class name based on the presence of @WebAppConfiguration on the test
class.
- Tests in the spring-test-mvc module no longer use a custom
ContextLoader to load a WebApplicationContext. Instead, they now
rely on new core functionality provided in this commit.
Issue: SPR-5243
This commit adds the spring-test-mvc project [1] to the Spring
Framework as part of the spring-test module.
The sources are added as a root-level project called "spring-test-mvc"
instead of under "spring-test" because the new sources need to be
compiled with Servlet 3 while the current "spring-test" sources require
Servlet 2.5 and the Eclipse IDE does not support having different
classpaths for the same project.
The Gradle build produces a single spring-test jar that contains
sources from both "spring-test" and "spring-test-mvc". This merge is
made possible through merge-dist.gradle as follows:
- jar tasks of the "from" project execute tasks of the "to" project
- "to" project is added to the classpath of the "from" project
- "to" project pom is updated with entries from the "from" project
For further details see documentation in merge-dist.gradle.
Special thanks to everyone who contributed to the initial development
of the Spring MVC Test framework:
Arjen Poutsma <poutsma@mac.com>
Craig Walls <cwalls@vmware.com>
Frans Flippo <fransflippo@utopia.orange11.nl>
Harry Lascelles <harry@firstbanco.com>
Irfan <mail.urfi@gmail.com>
Jörg Rathlev <joerg.rathlev@s24.com>
Keesun Baik <whiteship2000@gmail.com>
Keesun Baik <whiteship@epril.com>
Matthew Reid <matthew.reid@nakedwines.com>
Nils-Helge Garli Hegvik <Nils-Helge.Hegvik@telenor.com>
Rob Winch <rwinch@vmware.com>
Scott Frederick <sfrederick@vmware.com>
Sven Filatov <sven.filatov@gmail.com>
Thomas Bruyelle <thomas.bruyelle@gmail.com>
youngm <youngm@gmail.com>
[1]: https://github.com/SpringSource/spring-test-mvc
Issue: SPR-9859, SPR-7951
Rossen Stoyanchev
Sam Brannen
Phillip Webb
Rob Winch