ExchangeMutatorWebFilter now supports multiple mutator registrations
for the same request header id by creating a single composed function.
Issue: SPR-15250
This commit adds a common base class for server-less setup with the
option to configure a transformation function on the
ServerWebExchange for every request.
The transformation is applied through a WebFilter. As a result the
RouterFunction setup is now invoked behind a DispatcherHandler with
a HandlerMapping + HandlerAdapter.
Issue: SPR-15250
Currently the BOM versions are:
* reactor-core 3.0.6.BUILD-SNAPSHOT
* reactor-netty 0.6.2.BUILD-SNAPSHOT
This commit fixes as well a few deprecations in reactor-core.
The WebTestClient API no longer provides access to a base
ExchangeResult without a decoded response body.
Instead the response has to be decoded first and tests can then
access the EntityExchangeResult and FluxExchangeResult sub-types.
The WiretapConnector now decorated the ClientHttpRequest & Response
in order to intercept and save the actual content written and read.
The saved content is now incorporated in the diagnostic output but may
be used for other purposes as well (e.g. REST Docs).
Diagnostic information about an exchange has also been refactored
similar to command line output from curl.
Clearly separate how the result of an exchange is represented before
the response body has been read (e.g. assertions on status and headers
only) vs later after the body is extracted to a representation
(assertions on the extracted body) or is decoded to Flux<T> (e.g. for
use with a StepVerifier).
WebTestClient now defines all the steps from setup to performing
an exchange and applying expectations.
The order of expectations now ensures the response status and headers
are verified first since that's available before the body is consumed
and also because it determines how the body is to be decoded, i.e.
error vs success scenarios.
There is now a built-in option for verifying the response as a Map
along with Map-specific assertions.
There are similar options for verifying the response as a List as well
as whether to "collect" the list or "take" the first N elements from
the response stream.
Rather than returning ExchangeActions that contains ExchangeInfo and
applies a chain of assertions, the exchange operation in WebTestClient
now has an extra step to decode the response.
The outcome of that is ExchangeResult<T>, parameterized with the
decoded body type, and containing the request and response details,
also providing access to built-inassertions via an assertThat()
instance method.
This approach lends itself better to decoding and asserting response
body types with generecis. It is also more friendly to using any
assertion library such as AssertJ since you get the result first
and then deal with assertions.
This commit changes the `assertXmlEqual` implementation to compare
expected and actual XML documents without considering the order of XML
nodes.
Issue: SPR-15156
Put assertBodyXyz options behind a common assertBody() entry point
currently including "isEmpty" and "asMap" but in the future others
related to JSON content or XPath for example.
Now that ExchangeActions provides method to access the ExchangeInfo
it has been removed from constructors of assertion classes that
already have ExchangeActions.
This commit removes the parameterisation from ClientRequest, similarly
to ServerResponse. Dropping the parameterisation facilitates a
ClientRequest.from method that also copies the body of the target
request.
SPR-15234 Work in Progress
Before this change the write Publisher was saved and Mono.empty()
returned from the write metohd which did not properly implement
the write contract since no writing ("consuming") was done.
This can be a problem in some cases. For example the request may appear
to succeed even if the publisher produces an error later when
subscribed to later after request handling completes.
This commit introduces a writeHandler function in the mock request and
response. By default it "writes" by consuming the content immediately,
which allows it to return a Mono<Void> that properly reflects when
writing is done, and it also caches the data so it may be replayed
later for test assertions.
For streaming scenario a custom writeHandler may be registered which
allows the custom handling to determine how long to stream before
cancelling so request handling may complete.
Issue: SPR-14590
Prior to this commit, SpringJUnit4ConcurrencyTests was broken due to
recent additions of test methods in SampleTests.
This commit fixes the broken test by removing hard coded constants and
replacing them with dynamic lookups for JUnit 4 @Test methods.
This commit ensures that verifying a request, which includes finding
and updating expectations, is done synchronously to avoid concurrent
modification exceptions.
Technically SimpleRequestExpectationManager is not even expected to see
concurrent requests by definition but with
UnorderedRequestExpectationManager it can happen.
Issue: SPR-15029
MockServerHttpRequest and MockServerHttpResponse now extend the same
abstract base classes that server-specific implementations do and
therefore approximate their behavior more closely.
As an immediate consequence MockServerHttpRequest is read-only after
it is created. Instead it now exposes static builder methods similar
to those found in RequestEntity. This enforces more strictness as well
as recycling of requests in tests and provides nicer builder methods.
To simplify tests DefaultServerWebExchange now offers a constructor
with just a request and response, and automatically creating a
DefaultWebSessionManager.
The spring-test module now also contains client-side reactive mock
request and response implementations. The mock client request extends
the same AbstractClientHttpRequest as client-specific implementations
do. There is no abstract base class for client responses.
Issue: SPR-14590
After the upgrade to JUnit Jupiter 5.0 M3, JUnit Jupiter tests in the
Spring build were no longer executed due to the introduction of a
default test class name pattern.
This commit addresses this issue by making use of the
@IncludeClassNamePatterns to specify that *TestCase test classes should
be executed within the org.springframework.test.context.junit.jupiter
package.
This commit polishes previous one by also accepting
generic types explicitly declared with a class that
extends DataBuffer allowing to write Flux<DefaultDataBuffer>
for example.
Issue: SPR-14952
This modifies the signature of
ReactiveHttpOutputMessage#writeAndFlush(...) in order to
be able to use Flux<Flux<DataBuffer>> objects as arguments of
this method.
Issue: SPR-14952
This commit introduces the `DispatcherServletCustomizer` callback
interface that can be used to customize the `DispatcherServlet` that a
`MockMvc` is using.
Previously, only the `dispatchOptions` flag can be customized. This
commit allows to customize any property of `DispatcherServlet` before it
is initialized.
Issue: SPR-14277
Prior to this commit, when using @EnabledIf or @DisabledIf in Spring's
JUnit Jupiter support, the test's ApplicationContext was always eagerly
loaded, even if the ApplicationContext would never be used (i.e., the
test was disabled). This behavior can lead to undesirable side effects
-- for example, attempting to load an application context that requires
services only available on the CI server when the test is not actually
running on the CI server.
This commit addresses this issue by introducing new boolean
`loadContext` flags in @EnabledIf and @DisabledIf. By default these
flags are set to false which means that the user's test application
context will not be loaded to evaluate the expression. On the contrary,
a dummy application context will be loaded instead, and expressions
will be evaluated against that dummy context. Consequently, if the user
wishes to interact with properties from the Spring Environment or with
beans from the test application context, the `loadContext` must be
explicitly set to true.
In addition, expressions which evaluate to a String must now evaluate
to exactly "true" or "false" (ignoring case and surrounding whitespace).
Issue: SPR-14649
String with version 5 the name of Java Platform, Enterprise Edition
changed from J2EE to Java EE. However a lot of the documentation still
uses the term J2EE.
This commit includes the following changes:
* replace J2EE with Java EE where appropriate
This is not a blind search and replace. The following occurrences
remain unchanged:
* references to old J2EE releases, most notably 1.3 and 1.4.
* references to "Expert One-On-One J2EE Design and Development"
* references to "Core J2EE patterns"
* XML namespaces
* package names
Issue: SPR-14811
See gh-1206
Prior to this commit, the redirectedUrl() and forwardedUrl() methods in
MockMvcResultMatchers supported fully constructed URLs and URLs
containing Ant-style path patterns. However, URI templates were not
supported for these result matchers even though the request path can be
built using URL templates -- for example, via the get() and post()
methods in MockMvcRequestBuilders.
This commit addresses this shortcoming by allowing users to supply a
URL template instead of a fully constructed URL to redirectedUrl() and
forwardedUrl(). To populate the URL template, template variables may be
supplied to redirectedUrl() and forwardedUrl() as var-args.
Issue: SPR-14790
Commit e65a1a4372 introduced support in PrintingResultHandler for only
printing the request or response body in the Spring MVC Test framework
if the content type is known to be text-based (e.g., plain text, HTML,
XHTML, XML, JSON, etc.). For unknown content types the body is assumed
to be text-based and is therefore always printed. The latter behavior,
however, is undesirable since the content may in fact not be text-based.
This commit addresses this issue by making the printing of the request
or response body an opt-in feature. Specifically, if a character
encoding has been set, the request or response body will be printed by
the PrintingResultHandler. Note, however, that the character encoding
is set to ISO-8859-1 in MockHttpServletResponse by default.
In addition, MockHttpServletRequest's getContentAsString() method now
throws an IllegalStateException if the character encoding has not been
set.
Issue: SPR-14776
Prior to this commit, PrintingResultHandler always printed the request
or response body regardless of its content type. For binary content,
however, the output was unreadable and therefore useless.
This commit addresses this issue by only printing the request or
response body if it is "printable" (i.e., if its content type is known
to be text-based such as plain text, HTML, XHTML, XML, JSON, etc.). If
the content type is unknown (e.g., unspecified for the HTTP request in
the test), it is assumed that the body is printable.
Issue: SPR-14776
Prior to this commit, the PrintingResultHandler used by the various
print() and log() methods in Spring MVC Test printed the response body
but not the request body.
Since request bodies are sometimes generated programmatically, however,
it can be beneficial to have the dynamically generated request body
logged as well.
This commit therefore prints the request body in PrintingResultHandler
by delegating to the recently introduced getContentAsString() method in
MockHttpServletRequest.
Issue: SPR-14717
In order to improve debugging and logging within test suites, this
commit introduces getContentAsByteArray() and getContentAsString()
methods in MockHttpServletRequest, analogous to the existing methods in
MockHttpServletResponse.
Issue: SPR-14717
Whereas the existing TestContextConcurrencyTests verify support for
concurrency in the TestContextManager and TestContext, this commit
introduces SpringJUnit4ConcurrencyTests that verify support for
concurrent test execution in Spring's JUnit 4 support, namely in the
SpringRunner, SpringClassRule, and SpringMethodRule.
The tests executed by this new test class come from a hand-picked
collection of test classes within the test suite that is intended to
cover most categories of tests that are currently supported by the
TestContext Framework on JUnit 4.
Note, however, that the chosen test classes intentionally do not
include any classes that fall under the following categories.
- tests that make use of Spring's @DirtiesContext support
- tests that make use of JUnit 4's @FixMethodOrder support
- tests that commit changes to the state of a shared in-memory database
Issue: SPR-5863
This commit improves the exception message thrown when a test's
ApplicationContext is no longer active by explaining that the cause
may be due to parallel test execution.
Issue: SPR-5863
Prior to this commit, executing tests concurrently in the TestContext
Framework (TCF) was unsupported and typically lead to unpredictable
results.
This commit addresses this core issue by supporting concurrent
execution in the TestContextManager and the DefaultTestContext.
Specifically, the TestContextManager now uses ThreadLocal storage for
the current TestContext, thereby ensuring that any registered
TestExecutionListeners and the TestContextManager itself operate on a
TestContext specific to the current thread.
In order to avoid repeatedly incurring the costs of the overhead of the
TCF bootstrapping process, the original TestContext built by the
TestContextBootstrapper is used as a template which is then passed to
the copy constructor of the concrete implementation of the TestContext
to create the context for the current thread. DefaultTestContext now
implements such a copy constructor, and all concrete implementations of
TestContext are encouraged to do the same.
If the TestContext built by the TestContextBootstrapper does not
provide a copy constructor, thread-safety and support for concurrency
are left completely to the implementation of the concrete TestContext.
Note, however, that this commit does not address any thread-safety or
concurrency issues in the ContextLoader SPI or its implementations.
Issue: SPR-5863
This commit inlines the basic implementation of AttributeAccessorSupport
and converts the LinkedHashMap to a ConcurrentHashMap.
In addition, attributes are now included in toString().
Issue: SPR-5863
This commit introduces integration tests that verify the expected
behavior for @Nested tests in conjunction with the SpringExtension for
JUnit Jupiter, including automatic application of
TestExecutionListeners to the enclosing test instance of a @Nested
test instance.
Issue: SPR-14150
Due to restrictions imposed by JUnit 4, the SpringClassRule must be
declared as a public static field, which makes it impossible to be
declared directly within a nested (i.e., inner) test class.
This commit demonstrates a work-around that makes it possible to use
the SpringClassRule and SpringMethodRule in a nested (i.e., inner) test
class when using a custom JUnit 4 runner such as the
HierarchicalContextRunner from Stefan Bechtold.
The trick is to have inner test classes extend a class that properly
declares the SpringClassRule and SpringMethodRule. The
SpringRuleConfigurer in this commit serves as an example.
Note, however, that each such nested test class must declare its own
@ContextConfiguration. Furthermore, TestExecutionListeners in the
Spring TestContext Framework are not applied to the enclosing instance
of such an inner test class, meaning that @Autowired fields in the
enclosing instance will not be injected, etc.
Issue: SPR-14150
This commit picks up where SPR-14614 left off by introducing a new
@EnabledIf annotation to serve as a logical companion to @DisabledIf.
In addition, this commit extracts common logic from DisabledIfCondition
into a new AbstractExpressionEvaluatingCondition base class which the
new EnabledIfCondition also extends.
An @EnabledOnMac annotation is also included in the Javadoc as well as
in the test suite to demonstrate support for custom composed annotations.
Issue: SPR-14644
Prior to this commit, the DisabledIfCondition did not trim whitespace
from expressions configured via @DisabledIf. Consequently, results such
as " true " would evaluate to "false".
This commit fixes this problem by trimming all expressions configured
via @DisabledIf.
Issue: SPR-14614
This commit introduces tests for DisabledIfCondition that verify actual
condition evaluation results and exception handling; whereas, the
existing tests in DisabledIfTestCase only test the "happy paths" and
standard cases.
Issue: SPR-14614
- Extracted stand-alone DisabledIfCondition from the SpringExtension
so that the condition is only evaluated when necessary.
- Simplified implementation of DisabledIfCondition.
- Overhauled and extended logging in DisabledIfCondition.
- DisabledIfCondition now throws an IllegalStateException if @DisabledIf
is not present on the test element or if the expression does not
evaluate to a String or Boolean.
- Each generated ConditionEvaluationResult now includes the actual
expression in the default reason.
- @DisabledIf is now auto-configured to be evaluated by the
DisabledIfCondition since it is now meta-annotated with
@ExtendWith(DisabledIfCondition.class)
- Overhauled documentation for @DisabledIf and provided standard
examples as well as an @DisabledOnMac annotation to demonstrate
support for custom composed annotations.
Issue: SPR-14614
This commit introduces @DisabledIf annotation that takes SpEL as a
condition. The condition is evaluated at run time whether to disable
JUnit 5 (Jupiter) test method/class.
Issue: SPR-14614
This change adds support for a target type in JsonPath assertions in
Spring MVC Test.
The existing assertValue(String expression, Object expectedValue)
transparently falls back on using an alternative JsonPath API that
allows specifying the target type to coerce to.
There is also a new overloaded method
assertValue(String expression, Matcher<T> matcher, Class<T> targetType)
for use with Hamcrest matchers where the target type can be specified.
Issue: SPR-14498
Previously invoking HtmlUnitRequestBuilder merge caused the pathInfo of
the parent to be corrupted. This could additional invocations with the
same parent.
This fix ensures that the parent is no longer directly used. Instead,
we create a copy of the parent by merging the parent that was passed in
with the copy.
Fixes SPR-14584
xmlunit 2.1.0 is the latest release for xmlunit.
Most of the xmlunit functionality used within spring-framework
was done through the xmlunit 1.x helper class
`org.custommonkey.xmlunit.XMLAssert`.
As of xmlunit 2.0.0 most of the XML comparison methods are done
through hamcrest matchers exposed by the xmlunit-matchers
library. In some cases during the migration, the matchers
had to be customized with custom `NodeMatcher` or
`DifferenceEvaluator` instances in order to keep the assertions
correct (they were performed with xmlunit 1.x previously).
Issue: SPR-14043
Prior to this commit, a dynamic test in
FailingBeforeAndAfterMethodsSpringExtensionTestCase was failing but for
the wrong reason. Namely, the @Configuration class was private which
resulted in an IllegalStateException being thrown, when in fact
an AssertionFailedError was expected.
This commit addresses this by introducing an explicit check for an
AssertionFailedError.
Issue: SPR-4365
Prior to this commit, if multiple TestExecutionListener 'after' methods
threw an exception, only the first such exception was rethrown.
Subsequent exceptions were logged, but there was no way to access or
process them other than via the log file.
This commit addresses this shortcoming by making use of the support for
suppressed exceptions introduced in Java 7. Specifically, if multiple
TestExecutionListener 'after' methods throw an exception, the first
exception will be rethrown with subsequent exceptions suppressed in the
first one.
Issue: SPR-14459
This commit makes use of the new Supplier<String> variants of utility
methods in org.springframework.util.Assert within the spring-test
module.
Issue: SPR-14450
SPR-14055 introduced first-class support for the Java 8 Parameter API.
This commit therefore replaces the MethodParameterFactory with use of
the new SynthesizingMethodParameter.forParameter(Parameter) factory
method.
Issue: SPR-13575
This commit adds a test runtime dependency on log4j 2 for every project
and migrates all log4j.properties files to log4j2-test.xml files.
Issue: SPR-14431
This commit also removes the corresponding deprecated Servlet MVC variant and updates DispatcherServlet.properties to point to RequestMappingHandlerMapping/Adapter by default.
Issue: SPR-14129
This commit introduces initial support for JUnit Jupiter (i.e., the new
programming and extension models in JUnit 5) in the Spring TestContext
Framework.
Specifically, this commit introduces the following.
- SpringExtension: an implementation of multiple extension APIs from
JUnit Jupiter that provides full support for the existing feature set
of the Spring TestContext Framework. This support is enabled via
@ExtendWith(SpringExtension.class).
- @SpringJUnitConfig: a composed annotation that combines
@ExtendWith(SpringExtension.class) from JUnit Jupiter with
@ContextConfiguration from the Spring TestContext Framework.
- @SpringJUnitWebConfig: a composed annotation that combines
@ExtendWith(SpringExtension.class) from JUnit Jupiter with
@ContextConfiguration and @WebAppConfiguration from the Spring
TestContext Framework.
Issue: SPR-13575
Prior to this commit, any attempt to include a bean of type
ServletServerContainerFactoryBean in the WebApplicationContext for an
integration test class annotated with @WebAppConfiguration in
conjunction the Spring TestContext Framework (TCF) would have resulted
in an IllegalStateException stating that "A ServletContext is required
to access the javax.websocket.server.ServerContainer instance."
In such scenarios, the MockServletContext was in fact present in the
WebApplicationContext; however there was no WebSocket ServerContainer
stored in the ServletContext.
This commit addresses this issue by introducing the following.
- MockServerContainer: a private mock implementation of the
javax.websocket.server.ServerContainer interface.
- MockServerContainerContextCustomizer: a ContextCustomizer that
instantiates a new MockServerContainer and stores it in the
ServletContext under the attribute named
"javax.websocket.server.ServerContainer".
- MockServerContainerContextCustomizerFactory: a
ContextCustomizerFactory which creates a
MockServerContainerContextCustomizer if WebSocket support is present
in the classpath and the test class is annotated with
@WebAppConfiguration. This factory is registered by default via the
spring.factories mechanism.
Issue: SPR-14367
ReflectionTestUtils invokes toString() on target objects in order to
build exception and logging messages, and prior to this commit problems
could occur if the invocation of toString() threw an exception.
This commit addresses this issue by ensuring that all invocations of
toString() on target objects within ReflectionTestUtils are performed
safely within try-catch blocks.
Issue: SPR-14363
Previously MockMvcWebConnection did not update the cookie manager with the
cookies from MockHttpServletResponse. This meant that newly added cookies
are not saved to the cookie manager and thus are not presented in the next
request.
This commit ensures that MockMvcWebConnection stores the response cookies
in the cookie manager.
Issue: SPR-14265
Prior to Java 8 it never really made much sense to author integration
tests using interfaces. Consequently, the Spring TestContext Framework
has never supported finding test-related annotations on interfaces in
its search algorithms.
However, Java 8's support for interface default methods introduces new
testing use cases for which it makes sense to declare test
configuration (e.g., @ContextConfiguration, etc.) on an interface
containing default methods instead of on an abstract base class.
This commit ensures that all non-repeatable, class-level test
annotations in the Spring TestContext Framework can now be declared on
test interfaces. The only test annotations that cannot be declared on
interfaces are therefore @Sql and @SqlGroup.
Issue: SPR-14184
Prior to this commit, @BeforeTransaction and @AfterTransaction could
only be declared on methods within test classes. However, JUnit 5 as
well as some existing third-party Runner implementations for JUnit 4
already support Java 8 based interface default methods in various
scenarios -- for example, @Test, @BeforeEach, etc.
This commit brings the Spring TestContext Framework up to date by
supporting the declaration of @BeforeTransaction and @AfterTransaction
on interface default methods.
Issue: SPR-14183
Previously MockWebResponseBuilder would use the cookie domain of the cookie
received from MockMvc response. This caused problems because the cookie
domain can be null, but HtmlUnit forbids a null domain.
This commit defaults the domain of the cookie to the domain of the
WebRequest.
Issues SPR-14169
This commit introduces @Ignore'd tests for future support for declaring
@BeforeTransaction and @AfterTransaction on interface default methods.
Issue: SPR-14183
Previously HtmlUnitRequestBuilder did not decode parameter names. This
means if a parameter like row[0] was submittted it would be encoded as
row%5B0%5D When the HttpServletRequest was created the parameter name would
not be decoded so the parameter name row[0] would not be found.
This commit ensures that HTTP parameter names are decoded.
Issue SPR-14177
This commit introduces a new method in TestPropertySourceUtils that
allows properties files to be added directly to the environment without
the need for a ConfigurableApplicationContext upfront; however, a
ResourceLoader is still necessary.
Issue: SPR-14131
Prior to this commit, the size of the ApplicationContext cache in the
Spring TestContext Framework could grow without bound, leading to
issues with memory and performance in large test suites.
This commit addresses this issue by introducing support for setting the
maximum cache size via a JVM system property or Spring property called
"spring.test.context.cache.maxSize". If no such property is set, a
default value of 32 will be used.
Furthermore, the DefaultContextCache has been refactored to use a
synchronized LRU cache internally instead of a ConcurrentHashMap. The
LRU cache is a simple bounded cache with a "least recently used" (LRU)
eviction policy.
Issue: SPR-8055
JSON payloads are sometimes prepended with a static string prefix
to prevent Cross Site Scripting Inclusion attacks (XSSI).
Prior to this commit, doing so would fail the MockMvc
`JsonPathResultMatchers` since they're considering the whole response as
the JSON payload.
This commit adds a new `JsonPathResultMatchers.prefix` method that
configures the matchers to check for the presence of that string (i.e.
fail if it's not there) and only consider the rest of the response body
as the JSON payload for other assertions.
Issue: SPR-13577
Previously MockMvc builders failed to share the WebConnection used for
managing cookies in the MockMvcWebConnection. This meant that the various
CookieManagers would have different states.
This commit ensures that the WebConnection is set on the
MockMvcWebConnection.
Fixes SPR-14066
This commit introduces a test to demonstrate that inlined properties
override properties loaded from Properties files in
@TestPropertySource.
Issue: SPR-14068
This commit adds support for unwrapping proxies in the setField() and
getField() methods in ReflectionTestUtils.
Instead of always accessing fields directly on the supplied
targetObject (which may be a proxy), AopTestUtils is now used to obtain
the potential ultimateTargetObject which is then used for accessing
fields.
Issue: SPR-14050
Allow third-parties to contribute ContextCustomizers that can customize
ApplicationContexts created by the Spring TestContext Framework (TCF)
before they are refreshed.
A customizer may be provided via a ContextCustomizerFactory which is
registered with `spring.factories`. Each factory is consulted whenever
a new ApplicationContext needs to be created by the TCF. Factories may
inspect various details about the test and either return a new
ContextCustomizer or null.
ContextCustomizers are similar to ApplicationContextInitializers and
may perform any number of tasks, including bean registration, setting
of active profiles, etc.
Issue: SPR-13998
Add a ServletTestExecutionListener.ACTIVATE_LISTENER attribute which
can be set on the TestContext to trigger activation of the listener
even if a `@WebAppConfiguration` is not present.
Issue: SPR-14035
Prior to this commit, the @ContextConfiguration annotation was required
to be present even if default XML files, Groovy scripts, or
@Configuration classes were detected; however, in such cases the
@ContextConfiguration was typically declared empty and therefore
seemingly unnecessary boilerplate.
This commit permits @ContextConfiguration to be omitted whenever it can
be reasonably deduced. Consequently, integration tests such as the
following are now supported.
@RunWith(SpringRunner.class)
public class MyTest {
@Autowired String myBean;
@Test public void example() { /* ... */ }
@Configuration
static class Config {
@Bean String myBean() {
return "Hello";
}
}
}
Issue: SPR-13955
Update @WebAppConfiguration so that it no longer directly specifies
a TestContextBootstrapper. This allows third parties to use the
annotation in combination with their own bootstrapper.
BootstrapUtils now provides the detection logic for when
WebTestContextBootstrapper should be used.
Issue: SPR-13991
This commit changes the visibility of the getTestContext() method in
TestContextManager from 'protected' to 'public' in order to support
test method injection in JUnit 5 and similar use cases.
Issue: SPR-14011
This commit demonstrates how to register one or more @Configuration
classes via an ApplicationContextInitializer in a composed annotation so
that certain @Configuration classes are always registered whenever the
composed annotation is used, even if the composed annotation is used to
declare additional @Configuration classes.
Before this commit, specifying the charset to use with produces or
consumes @RequestMapping attributes resulted in default charset
loss. That was really annoying for JSON for example, where using
UTF-8 charset is mandatory in a lot of use cases.
This commit adds a defaultCharset property to
AbstractHttpMessageConverter in order to avoid losing the
default charset when specifying the charset with these
@RequestMapping attributes.
It changes slightly the default behavior (that's why we have waited
4.3), but it is much more error prone, and will match with most
user's expectations since the charset loss was accidental in most
use cases (users usually just want to limit the media type supported
by a specific handler method).
Issue: SPR-13631
This commit introduces the following common composed annotations for
@RequestMapping in Spring MVC and Spring MVC REST.
- @GetMapping
- @PostMapping
- @PutMapping
- @DeleteMapping
- @PatchMapping
Issue: SPR-13992
Prior to this commit, the TransactionalTestExecutionListener required
@Transactional test methods to be public; however, neither TestNG nor
JUnit 5 require that @Test methods are public. Consequently, non-public
transactional test methods silently run *without* a transaction.
This commit removes the 'public' restriction on transactional test
methods by setting the 'publicMethodsOnly' flag in
AnnotationTransactionAttributeSource to false.
Issue: SPR-14000
In order to align with the relaxed programming models of TestNG and the
upcoming JUnit 5 (with regard to method visibility), this commit
removes the requirement that @BeforeTransaction and @AfterTransaction
methods must be 'public'.
Issue: SPR-13997
This commit introduces a SpringRunner extension of
SpringJUnit4ClassRunner that is intended to be used as an 'alias' for
SpringJUnit4ClassRunner, primarily in order to simplify configuration
of JUnit 4 based integration tests.
Developers can use this alias as follows:
@RunWith(SpringRunner.class)
public class MySpringIntegrationTests { ... }
Issue: SPR-13954
MockRestServiceServer now provides static methods for builder-style
creation of MockRestServiceServer. This includes an option ignore
the order of declaration expected requests.
Issue: SPR-11365
This commit factors out the logic to declare and manage expectations
including matching them to requests and verifying at the end behind
a commong abstraction.
MockRestServiceServer delegates to the new abstraction and is no longer
aware of how that's done. There are two implementations, one for
ordered and another for unordered expectation.
Issue: SPR-11365
Before this commit RequestMatcherClientHttpRequest served both as
API to define request expectations, i.e. ResponseActions, as well as
the implementation of ClientHttpRequest representing actual requests.
DefaultResponseActions replaces this class as a simple holder of
expected requests and mock responses. MockRestServiceServer is then
responsible to match request expectations and create a mock response.
Issue: SPR-11365
Prior to this commit, the transaction manager and data source look-up
algorithms in the Spring TestContext Framework were not capable of
retrieving 'primary' beans of those types, even though 'primary' beans
are supported in production as well as for injecting dependencies into
test instances. Specifically, if there was more than one transaction
manager or data source bean and one of them was flagged as 'primary',
the retrieveTransactionManager() and retrieveDataSource() methods in
TestContextTransactionUtils would simply return null for such beans.
This commit updates TestContextTransactionUtils by adding support for
looking up primary transaction managers and data sources.
Issue: SPR-13891
Prior to this commit, a @Transactional integration test would silently
be executed without a transaction if the transaction manager could not
be retrieved from the application context -- for example, it no such
bean was defined or if multiple beans were present but none satisfied
the qualifier.
This commit addresses this issue by throwing an IllegalStateException
if the PlatformTransactionManager cannot be retrieved for a
@Transactional test.
Issue: SPR-13895
Spring MVC Test now parses application/x-www-form-urlencoded request
content and populates request parameters from it.
This can be useful when running client-side tests against a MockMvc
via MockMvcClientHttpRequestFactory.
Issue: SPR-13733
Prior to this commit, Spring MVC Test only supported HTTP methods GET,
POST, HEAD, OPTIONS, PUT, PATCH, DELETE, TRACE and multipart file
upload. This change adds generic methods to MockMvcRequestBuilders in
order to allow testing of arbitrary HTTP methods in a Spring MVC
application.
Issue: SPR-13719
Rossen Stoyanchev
Sam Brannen
Juergen Hoeller
Brian Clozel
Arjen Poutsma
Jan-Espen Oversand
Phillip Webb
Stephane Nicoll
Masayasu Yamamoto
Vedran Pavić
Sebastien Deleuze
schjan79
Drummond Dawson
Daniel Fernández
Philippe Marschall
Tadaya Tsuyukubo
Rob Winch
Marius Grama
Vladimir L
nkjackzhang
Johnny Lim
Marten Deinum
Kamill Sokol