Prior to this commit, WebTestClient only supported "lenient" comparison
of the expected JSON body.
This commit introduces an overloaded variant of `json()` in the
BodyContentSpec that accepts an additional boolean flag to specify
whether a "strict" comparison should be performed.
This new feature is analogous to the existing support in MockMvc.
Closes gh-27993
Prior to this commit, the PrintingResultHandler in MockMvc -- typically
invoked via .andDo(print()) -- printed an `application/json` response
body using the default encoding (ISO-8859-1), which resulted in UTF-8
characters being garbled.
Since an `application/json` response is implicitly encoded using UTF-8,
the PrintingResultHandler now infers UTF-8 encoding for such response
bodies.
Closes gh-27926
Although this commit only applies to test classes, it serves to reduce
the noise when searching for undesirable usage of StringBuffer in
production code.
Prior to this commit, the default CacheAwareContextLoaderDelegate could
be configured by extending AbstractTestContextBootstrapper and
overriding getCacheAwareContextLoaderDelegate(); however, this required
that the user configure the custom TestContextBootstrapper via
@BootstrapWith.
This commit introduces a new
"spring.test.context.default.CacheAwareContextLoaderDelegate" property
that can be configured via a JVM system property or via the
SpringProperties mechanism. BootstrapUtils uses this new property to
load the default CacheAwareContextLoaderDelegate. If the property is
not defined, BootstrapUtils will fall back to creating a
DefaultCacheAwareContextLoaderDelegate as it did previously.
This allows third parties to configure the default
CacheAwareContextLoaderDelegate transparently for the user -- for
example, to intercept context loading in order to load the context in a
different manner -- for example, to make use of ahead of time (AOT)
techniques for implementing a different type of ApplicationContext at
build time.
Closes gh-27540
In order to be able to use text blocks and other new Java language
features, we are upgrading to a recent version of Checkstyle.
The latest version of spring-javaformat-checkstyle (0.0.28) is built
against Checkstyle 8.32 which does not include support for language
features such as text blocks. Support for text blocks was added in
Checkstyle 8.36.
In addition, there is a binary compatibility issue between
spring-javaformat-checkstyle 0.0.28 and Checkstyle 8.42. Thus we cannot
use Checkstyle 8.42 or higher.
In this commit, we therefore upgrade to spring-javaformat-checkstyle
0.0.28 and downgrade to Checkstyle 8.41.
This change is being applied to `5.3.x` as well as `main` in order to
benefit from the enhanced checking provided in more recent versions of
Checkstyle.
Closes gh-27481
In order to allow developers to execute TestNG tests in Eclipse IDE
without installing the TestNG plugin for Eclipse, this commit introduces
a JUnit Platform @Suite class that can be executed within the IDE.
See gh-27407
It happens very often that WebTestClient is used in heavyweight
integration tests, and it's a hindrance to developer productivity to
fix one failed assertion after another. Soft assertions help a lot by
checking all conditions at once even if one of them fails.
This commit introduces a new expectAllSoftly(..) method in
WebTestClient to address this issue.
client.get().uri("/hello")
.exchange()
.expectAllSoftly(
spec -> spec.expectStatus().isOk(),
spec -> spec.expectBody(String.class).isEqualTo("Hello, World")
);
Closes gh-26969
It happens very often that MockMvc is used in heavyweight integration
tests. It's no use to waste time to check if another condition has been
fixed or not. Soft assertions help a lot by checking all conditions at
once even if one of them fails.
See gh-26917
Co-authored-by: Sach Nguyen <sachnbbkhn@gmail.com>
Prior to this commit, if the user tested file upload support with
HtmlUnit and MockMvc by invoking HtmlFileInput.setData() instead of
HtmlFileInput.setFiles(), the in-memory file data was simply ignored.
This commit addresses this issue by creating a MockPart from the
in-memory data in HtmlUnitRequestBuilder.
Closes gh-27199
To improve the developer experience and avoid the use of String
literals, this commit provides overloaded support via Charset for
character encoding in MockHttpServletRequestBuilder and
ContentResultMatchers.
Closes gh-27231
Commit e4b9b1fadb introduced support for setting the default character
encoding in MockHttpServletResponse.
This commit introduces support for configuring the default character
encoding in the underlying MockHttpServletResponse used in MockMvc.
Closes gh-27230
Prior to this commit, MockMvc applied global ResultMatchers before
global ResultHandlers. This lead to unexpected scenarios where a
failing matcher would prevent a handler from being applied.
One concrete use case is `alwaysDo(print(System.err))` which should
print out MockMvc results for debugging purposes. However, if MockMvc is
configured with something like `alwaysExpect(content().string("?"))`
and the expectation fails, the user will never see the expected debug
output to help diagnose the problem.
This commit addresses this issue by applying global ResultHandlers
before ResultMatchers in MockMvc.
Closes gh-27225
Prior to this commit, it was possible to set the character encoding
in MockHttpServletResponse via setCharacterEncoding() or
setContentType(); however, those methods append "charset=..." to the
Content-Type header which may not be an acceptable side effect.
This commit addresses this shortcoming by introducing a new
setDefaultCharacterEncoding() in MockHttpServletResponse which allows
one to override the previously hard coded value of "ISO-8859-1". In
addition, setDefaultCharacterEncoding() does not modify the Content-Type
header.
The reset() method has also been updated to reset the character encoding
to the configured default character encoding.
Closes gh-27214
