This commit changes the name of two recently introduced methods in the
`MockRestRequestMatchers` class for header and queryParam. These have
been found to cause false negatives in user tests, due to the new
overload taking precedence in some cases.
Namely, using a `Matcher` factory method which can apply to both `List`
and `String` will cause the compiler to select the newest list overload,
by instantiating a `Matcher<Object>`.
This can cause false negatives in user tests, failing tests that used
to pass because the Matcher previously applied to the first String in
the header or queryParam value list. For instance, `equalsTo("a")`.
The new overloads are recent enough and this has enough potential to
cause an arbitrary number of user tests to fail that we break the API
to eliminate the ambiguity, by renaming the methods with a `*List`
suffix.
Closes gh-30220
Closes gh-30238
See gh-29953
See gh-28660
This commit adds a `header` variant and a `queryParam` variant to the
`MockRestRequestMatchers` API which take a single `Matcher` over the
list of values.
Contrary to the vararg variants, the whole list is evaluated and the
caller can choose the desired semantics using readily-available iterable
matchers like `everyItem`, `hasItems`, `hasSize`, `contains` or
`containsInAnyOrder`...
The fact that the previous variants don't strictly check the size of the
actual list == the number of provided matchers or expected values is
now documented in their respective javadocs.
See gh-28660
Closes gh-29953
This change restricts the maximum number of forwards in MockMvcWebConnection to 100,
in case a forward is configured in a way that causes a loop. This is necessary in HtmlUnit
backed tests, unlike in classic MockMvc tests in which the forwards are not actually resolved.
Closes gh-29483
Closes gh-29557
Co-authored-by: Simon Baslé <sbasle@vmware.com>
Prior to this commit, a recent change applied in gh-29125 changed the
behavior of `MockHttpServletRequest` instances. In case of an empty
request body, the returned `InputStream` would be static and could not
be reused across requests.
This could result in `java.io.IOException: Stream closed` exceptions if
a previous request was read.
This commit ensures that a new instance of an empty stream is returned
for each request instance.
Fixes gh-29901
SocketUtils was officially deprecated in 5.3.16 (gh-28052) and removed
in 6.0 M3 (gh-28054); however, there is still need for a subset of this
functionality in integration tests for testing scenarios in which it is
not possible for the system under test to select its own random port
(or rely on the operating system to provide an ephemeral port).
This commit therefore introduces a scaled down version in the
spring-test module called TestSocketUtils which supports retrieval of a
single TCP port.
See gh-29132
Prior to this commit, it was possible to register hints for individual
test classes programmatically via the
org.springframework.test.context.aot.TestRuntimeHintsRegistrar SPI;
however, that requires that a custom TestRuntimeHintsRegistrar be
registered via "META-INF/spring/aot.factories". In addition,
implementing a TestRuntimeHintsRegistrar is more cumbersome than using
the core mechanisms such as @Reflective, @ImportRuntimeHints, and
@RegisterReflectionForBinding.
This commit address this by introducing support for @Reflective and
@ImportRuntimeHints on test classes. @RegisterReflectionForBinding
support is available automatically since it is an extension of the
@Reflective mechanism.
Closes gh-29455
- Remove final modifier from private method
- Use StandardCharsets
- Remove unnecessary toString calls
- Remove unnecessary static modifiers
- Refactor to use enhanced switch
- Replace concatenated strings with text blocks
- Rely on auto-boxing where appropriate
- Remove unnecessary code
- Fix imports in Kotlin test classes
Closes gh-29413
Includes corresponding build upgrade to Tomcat 10.1.1 and Undertow 2.3.0
(while retaining runtime compatibility with Tomcat 10.0 and Undertow 2.2)
Closes gh-29435
Closes gh-29436
At the request of the Spring Boot team, ApplicationContextFailureProcessor
implementations are now loaded via the spring.factories mechanism
instead of supporting a single processor registered via subclasses of
AbstractTestContextBootstrapper.
This makes the retrieval and handling of processors internal to
DefaultCacheAwareContextLoaderDelegate, while simultaneously supporting
multiple processors that can be registered by anyone (i.e., not
limited to projects that implement custom TestContextBootstrappers).
See gh-28826
Closes gh-29387
This commit introduces an ApplicationContextFailureProcessor SPI in the
Spring TestContext Framework that allows third parties to process
failures that occur while a SmartContextLoader attempts to load an
ApplicationContext.
SmartContextLoader implementations must introduce a try-catch block
around the loading code and throw a ContextLoadException that wraps
the failed ApplicationContext and the cause of the failure.
Extensions of AbstractTestContextBootstrapper can configure an
ApplicationContextFailureProcessor by overriding the new protected
getApplicationContextFailureProcessor() method.
DefaultCacheAwareContextLoaderDelegate unwraps any ContextLoadException
and delegates to the configured ApplicationContextFailureProcessor for
processing.
Closes gh-28826
