Ideally, we should be able to reuse the ContextLoader that was resolved
in buildDefaultMergedContextConfiguration(); however, since we have
been informed that some implementations of resolveContextLoader()
mutate the state of the supplied ContextConfigurationAttributes to
detect default configuration classes, we need to invoke
resolveContextLoader() on the completeDefaultConfigAttributesList as
well in order not to break custom TestContextBootstrappers that exhibit
such side effects.
Closes gh-36390
This commit renames the
org.springframework.test.context.configuration.interfaces package to
org.springframework.test.context.config.interfaces in order to colocate
"config" related tests under the same package.
In Spring Framework 7.1, the TestContext Framework will reliably detect
all default context configuration within the type hierarchy or
enclosing class hierarchy (for @Nested test classes) above a given
test class; however, test suites may encounter failures once we make
that switch in behavior.
In order to help development teams prepare for the switch in 7.1, this
commit logs a warning similar to the following whenever default context
configuration is detected but currently ignored.
WARN - For test class [org.example.MyTests$NestedTests], the
following 'default' context configuration classes were detected but
are currently ignored: org.example.MyTests$Config. In Spring
Framework 7.1, these classes will no longer be ignored. Please update
your test configuration accordingly. For details, see:
https://docs.spring.io/spring-framework/reference/testing/testcontext-framework/ctx-management/default-config.html
See gh-31456
See gh-36392
Closes gh-36390
This commit also updates the Javadoc for the SpringExtension and
@SpringExtensionConfig to point out that the SpringExtension always
uses a test-class scoped ExtensionContext if
@TestInstance(Lifecycle.PER_CLASS) semantics are in effect.
Closes gh-36240
In commit 9711db787e, we introduced support for disabling test
application context pausing via a Spring property or JVM system
property, as follows.
-Dspring.test.context.cache.pause=never
However, users may actually be interested in keeping the pausing
feature enabled if contexts are not paused unnecessarily.
To address that, this commit introduces a new
PauseMode.ON_CONTEXT_SWITCH enum constant which is now used by default
in the DefaultContextCache.
With this new pause mode, an unused application context will no longer
be paused immediately. Instead, an unused application context will be
paused lazily the first time a different context is retrieved from or
stored in the ContextCache. This effectively means that an unused
context will not be paused at all if the next test class uses the same
context.
Although ON_CONTEXT_SWITCH is the now the default pause mode, users
still have the option to enable context pausing for all usage scenarios
(not only context switches) by setting the Spring property or JVM
system property to ALWAYS (case insensitive) — for example:
-Dspring.test.context.cache.pause=always
This commit also introduces a dedicated "Context Pausing" section in
the reference manual.
See gh-36117
Closes gh-36044
Spring Framework 7.0 introduced support for pausing inactive
application contexts between test classes and restarting them once they
are needed again. If pausing and restarting are fast, this feature does
not have a negative impact on test suites.
However, if the pausing or restarting of certain Lifecycle components
in the application context is slow, that can have a negative impact on
the duration of the overall test suite.
In gh-36044, we hope to find a way to avoid unnecessarily pausing an
application context after a test class if the same context is used by
the next test class that is run. That should help reduce the risk of a
negative impact caused by the pause/restart feature; however, for
certain scenarios that may not be enough. In light of that, this commit
introduces a mechanism for completely disabling the pausing feature via
a Spring property or JVM system property, as follows.
-Dspring.test.context.cache.pause=never
See gh-35168
See gh-36044
Closes gh-36117
Prior to this commit, we found in gh-35953 that using the `WebTestClient`
the following way leaks data buffers:
```
var body = client.get().uri("download")
.exchange()
.expectStatus().isOk()
.returnResult()
.getResponseBodyContent();
```
Here, the test performs expectations on the response status and headers,
but not on the response body. The WiretapConnector already supports this
case by subscribing to the Flux response body in those cases and
accumulating the entire content as a single byte[].
Here, the `DataBuffer` instances are not decoded by any `Decoder` and
are not released. This results in a memory leak.
This commit ensures that the automatic subscription in
`WiretapConnector` also releases the buffers automatically as the DSL
does not allow at that point to go back to performing body expectations.
Fixes gh-36050
Prior to this commit, if an enclosing test class (such as one annotated
with @SpringBootTest or simply @ExtendWith(SpringExtension.class))
was not annotated with @ContextConfiguration (or @Import with
@SpringBootTest), the ApplicationContext loaded for a @Nested test
class would not use any default context configuration for the enclosing
test class.
Effectively, a default XML configuration file or static nested
@Configuration class for the enclosing test class was not discovered
by the AbstractTestContextBootstrapper when attempting to build the
MergedContextConfiguration (application context cache key).
To address that, this commit introduces a new
resolveDefaultContextConfigurationAttributes() method in
ContextLoaderUtils which is responsible for creating instances of
ContextConfigurationAttributes for all superclasses and enclosing
classes. This effectively enables AbstractTestContextBootstrapper to
delegate to the resolved SmartContextLoader to properly detect a
default XML configuration file or static nested @Configuration class
even if such classes are not annotated with @ContextConfiguration.
Closes gh-31456
Prior to this commit, `RestTestClient` tests could only perform
expectations on the response without consuming the body. In this case,
the client could leak HTTP connections with the underlying HTTP library
because the response was not entirely read.
This commit ensures that the response is always fully drained before
performing expectations. The client is configured to buffer the response
content, so further body expectations are always possible.
Fixes gh-35784
If the RestClient was built with default message converters, then
in mutate, the saved builder also has 0 converters, and adding a
interferes with default registrations.
We need to check if there are no converters at all, and if so
use the default registrations.
See gh-35793
Since getApplicationContext() was originally not intended to be part of
the public API, its Javadoc is intentionally sparse. However, since it
is actually a public API used by third parties, this commit improves the
documentation for getApplicationContext() by pointing out that invoking
the method actually results in the context being eagerly loaded, which
may not be desired.
This commit also updates the Javadoc for supportsParameter() along the
same lines.
Closes gh-35764