In 49e5c84928 I unfortunately overlooked
several JUnit 4 based tests in the `junit4` package that should be
migrated to JUnit Jupiter.
This commit address those remaining test classes.
See gh-23451
See gh-34794
Closes gh-34813
Build and Deploy Snapshot / Build and Deploy Snapshot (push) Waiting to runDetails
Build and Deploy Snapshot / Verify (push) Blocked by required conditionsDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:false version:17], map[id:ubuntu-latest name:Linux]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:21], map[id:ubuntu-latest name:Linux]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:23], map[id:ubuntu-latest name:Linux]) (push) Waiting to runDetails
Deploy Docs / Dispatch docs deployment (push) Waiting to runDetails
This commit revises the implementation of TestConventions so that
existing JUnit Platform options from a pre-configured `test` task are
copied instead of overridden.
Closes gh-34827
Backport Bot / build (push) Has been cancelledDetails
Build and Deploy Snapshot / Build and Deploy Snapshot (push) Has been cancelledDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:false version:17], map[id:ubuntu-latest name:Linux]) (push) Has been cancelledDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:21], map[id:ubuntu-latest name:Linux]) (push) Has been cancelledDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:23], map[id:ubuntu-latest name:Linux]) (push) Has been cancelledDetails
Deploy Docs / Dispatch docs deployment (push) Has been cancelledDetails
Build and Deploy Snapshot / Verify (push) Has been cancelledDetails
In Spring Framework 5.2, we migrated most of the test suite from JUnit
4 to JUnit Jupiter; however, prior to this commit, several tests in the
spring-test module were still based on JUnit 4 unnecessarily.
Since we are now planning to deprecate our JUnit 4 support in 7.0, this
commit migrates our remaining JUnit 4 based tests to JUnit Jupiter
whenever feasible. In the process, test classes that previously resided
under the "junit4" package have been moved to new packages directly
under the "org.springframework.text.context" package, and several
classes have been renamed for greater clarity of purpose.
Consequently, the only remaining tests based on JUnit 4 are those tests
that are required to run with JUnit 4 in order to test our JUnit 4
support.
This commit also greatly simplifies exclusions for Checkstyle rules
pertaining to JUnit usage.
See gh-23451
See gh-34794
Closes gh-34813
This commit provides first-class support for Bean Overrides
(@MockitoBean, @MockitoSpyBean, @TestBean, etc.) with
@ContextHierarchy.
Specifically, bean overrides can now specify which ApplicationContext
they target within the context hierarchy by configuring the
`contextName` attribute in the annotation. The `contextName` must match
a corresponding `name` configured via @ContextConfiguration.
For example, the following test class configures the name of the second
hierarchy level to be "child" and simultaneously specifies that the
ExampleService should be wrapped in a Mockito spy in the context named
"child". Consequently, Spring will only attempt to create the spy in
the "child" context and will not attempt to create the spy in the
parent context.
@ExtendWith(SpringExtension.class)
@ContextHierarchy({
@ContextConfiguration(classes = Config1.class),
@ContextConfiguration(classes = Config2.class, name = "child")
})
class MockitoSpyBeanContextHierarchyTests {
@MockitoSpyBean(contextName = "child")
ExampleService service;
// ...
}
See gh-33293
See gh-34597
See gh-34726
Closes gh-34723
Signed-off-by: Sam Brannen <104798+sbrannen@users.noreply.github.com>
For bean override support (@MockitoBean, @TestBean, etc.), the logic
for field injection previously resided in the BeanOverrideRegistry
which resulted in a strange mixture of concerns.
To address that, this commit moves the field injection logic to the
BeanOverrideTestExecutionListener, and the BeanOverrideRegistry now
serves a single role, namely the role of a registry.
Closes gh-34726
Prior to this commit, the Test Bean Override feature provided support
for overriding beans based on qualifier annotations in several
scenarios; however, qualifier annotations got lost if they were
declared on the return type of the @Bean method for the bean being
overridden and the @BeanOverride (such as @MockitoBean) was based on
a supertype of that return type.
To address that, this commit sets the @BeanOverride field as the
"qualified element" in the RootBeanDefinition to ensure that qualifier
annotations are available for subsequent autowiring candidate
resolution.
Closes gh-34646
This commit removes the BDDMockito Checkstyle rule, since it did not
actually enforce the use of BDDMockito.
This commit also updates static imports to use Mockito instead of
BDDMockito where appropriate (automated via the Eclipse IDE Organize
Imports clean-up task).
Closes gh-34616
Prior to this commit, MockCookie.parse() failed with an
IllegalArgumentException when attempting to parse a custom attribute
with a value, such as "Version=1". This is a regression that was
inadvertently introduced in 7fc4937199
when adding support for the "Partitioned" attribute which does not
support a value.
This commit addresses this regression by parsing both the name and the
value from an optional, custom attribute.
See gh-31454
Closes gh-34575
This commit introduces a new loadContextForAotProcessing(...) variant
in AotContextLoader which accepts a RuntimeHints argument. This new
method is an interface default method which delegates to the existing
loadContextForAotProcessing(MergedContextConfiguration) variant for
backward compatibility.
In addition, the original loadContextForAotProcessing(...) variant is
now deprecated and has been converted to an interface default method
which throws an UnsupportedOperationException.
Note, however, that the framework now only invokes the new
loadContextForAotProcessing(...) variant within TestContextAotGenerator.
Closes gh-34513
Prior to this commit, `MockHttpServletResponse` would only support
adding a `Content-Language` once. Adding multiple header values would
always replace the content-language property in the response and the
entire header value.
This commit ensures that this behavior is supported.
Fixes gh-34488
This commit revisits the behavior of our `MockHttpServletResponse`
implementation with the javadoc clarifications applied in Servlet 6.1.
Prior to this change, adding or setting an HTTP response header with a
`null` name or value would not have the expected behavior:
* a `null` name should have no effect instead of throwing exceptions
* a `null` value when setting a header effectively removes the entry
from the response headers
Also, this commit ensures that `IllegalStateException` are thrown if
`getWriter` is called after a previous `getOutputStream` (and vice
versa).
Closes gh-34467
Prior to this commit, `MockHttpServletResponse#setHeader` would not
remove the header entry when given a `null` value, as documented in the
Servlet API.
This commit ensures that this behavior is enforced.
Fixes gh-34464
This commit adds missing `@since` tags for formField() and formFields in
MockHttpServletRequestDsl. See gh-34412 related issue.
Closes gh-34448
Signed-off-by: Johnny Lim <izeye@naver.com>
Prior to this commit, @MockitoSpyBean could only be declared on fields
within test classes, which prevented developers from being able to
easily reuse spy configuration across a test suite.
With this commit, @MockitoSpyBean is now supported at the type level
on test classes, their superclasses, and interfaces implemented by
those classes. @MockitoSpyBean is also supported on enclosing classes
for @Nested test classes, their superclasses, and interfaces
implemented by those classes, while honoring @NestedTestConfiguration
semantics.
In addition, @MockitoSpyBean:
- has a new `types` attribute that can be used to declare the type or
types to spy when @MockitoSpyBean is declared at the type level
- can be declared as a repeatable annotation at the type level
- can be declared as a meta-annotation on a custom composed annotation
which can be reused across a test suite (see the @SharedSpies
example in the reference manual)
To support these new features, this commit also includes the following
changes.
- MockitoSpyBeanOverrideProcessor has been revised to support
@MockitoSpyBean at the type level.
- The "Bean Overriding in Tests" and "@MockitoBean and
@MockitoSpyBean" sections of the reference manual have been fully
revised.
See gh-34408
Closes gh-33925
Prior to this commit, the order values of TestExecutionListener
implementations were hard-coded in their getOrder() methods.
To benefit users and integrators, this commit exposes those order values
as an ORDER constant in each TestExecutionListener.
See gh-34225
Closes gh-34404
Changes made to the Bean Override search algorithms in commit
9181cce65f resulted in a regression that caused tests to start failing
due to duplicate BeanOverrideHandlers under the following circumstances.
- An enclosing class (typically a top-level test class) declares a
@BeanOverride such as @MockitoBean.
- An inner class is declared in that enclosing class.
- A @Nested test class which extends that inner class is declared in
the same enclosing class.
The reason for the duplicate detection is that the current search
algorithm visits the common enclosing class twice.
To address that, this commit revises the search algorithm in
BeanOverrideHandler so that enclosing classes are only visited once.
See gh-33925
Closes gh-34324
Prior to this commit, test bean overrides (for example, @MockitoBean,
@TestBean, etc.) eagerly honored the name of the annotated field as a
fallback qualifier, effectively ignoring @Primary and @Fallback
semantics for certain use cases.
This led to situations where a bean override for a test would select a
different bean than the core container would for the same autowiring
metadata.
To address that, this commit revises the implementation of
BeanOverrideBeanFactoryPostProcessor so that @Primary and @Fallback
semantics are consistently honored before attempting to use the
annotated field's name as a fallback qualifier.
Closes gh-34374
Prior to this commit, @MockitoBean could only be declared on fields
within test classes, which prevented developers from being able to
easily reuse mock configuration across a test suite.
With this commit, @MockitoBean is now supported at the type level on
test classes, their superclasses, and interfaces implemented by those
classes. @MockitoBean is also supported on enclosing classes for
@Nested test classes, their superclasses, and interfaces implemented
by those classes, while honoring @NestedTestConfiguration semantics.
In addition, @MockitoBean:
- has a new `types` attribute that can be used to declare the type or
types to mock when @MockitoBean is declared at the type level
- can be declared as a repeatable annotation at the type level
- can be declared as a meta-annotation on a custom composed annotation
which can be reused across a test suite (see the @SharedMocks
example in the reference manual)
To support these new features, this commit also includes the following
changes.
- The `field` property in BeanOverrideHandler is now @Nullable.
- BeanOverrideProcessor has a new `default` createHandlers() method
which is invoked when a @BeanOverride annotation is found at the
type level.
- MockitoBeanOverrideProcessor implements the new createHandlers()
method.
- The internal findHandlers() method in BeanOverrideHandler has been
completely overhauled.
- The @MockitoBean and @MockitoSpyBean section of the reference
manual has been completely overhauled.
Closes gh-33925
As of gh-33847, method and field introspection is included by default
when a type is registered for reflection.
Many methods in ReflectionHintsPredicates are now mostly useless as their
default behavior checks for introspection.
This commit deprecates those methods and promotes instead invocation
variants. During the upgrade, developers should replace it for an
`onType` check if only reflection is required. If they were checking for
invocation, they should use the new 'onXInvocation` method.
Closes gh-34239
Code that compiles against the non-deprecated version does not see the
new constructor that has been introduced. As such, there is no way for
them to migrate to it without resorting to reflection.
This commit restores the deprecated constructor so that people can try
the latest version more easily.
Closes gh-34238
Prior to this commit, the search algorithm used to locate a @TestBean
factory method within a test class hierarchy incorrectly found factory
methods declared in subclasses or nested test classes "below" the class
in which the @TestBean field was declared. This resulted in "duplicate
bean override" failures for @TestBean overrides which are clearly not
duplicates but rather "overrides of an override".
This commit ensures that @TestBean factory method resolution is
consistent in type hierarchies as well as in enclosing class
hierarchies (for @Nested test classes) by beginning the search for a
factory method in the class which declares the @TestBean field.
Closes gh-34204
Prior to this commit, a @BeanOverride (such as @TestBean) for a
specific target bean which was declared in a superclass always took
precedence over a bean override for the same target bean in a subclass,
thereby rendering the bean override configuration in the subclass
useless. In other words, there was no way for a test class to override
a bean override declared in a superclass.
To address that, this commit switches from direct use of
ReflectionUtils.doWithFields() to a custom search algorithm that
traverses the class hierarchy using tail recursion for processing
@BeanOverride fields (delegating now to
ReflectionUtils.doWithLocalFields() in order to continue to benefit
from the caching of declared fields in ReflectionUtils).
Closes gh-34194
This change ensures that a request containing query parameters in the
array format `someArray[]=value` can be bound into a simple array in
constructors, even for cases where the array values don't have nested
properties.
The value resolver is directly called in the constructor case, before
any mutable properties are considered or even cleared (see
`WebDataBinder#adaptEmptyArrayIndices` method). As a result, we need to
accommodate the possibility that the request stores array elements under
the `name[]` key rather than `name`. This change attempts a secondary
lookup with the `[]` suffix if the type is a list or array, and the key
doesn't include an index.
Closes gh-34121
This change ensures that DataBinder can bind constructor with a Map
parameter that has no nested properties, but just simple values like
a String: `someMap[0]=exampleString`.
Integration tests have been added to cover similar cases that use the
ServletRequestDataBinder.
Closes gh-34043
This change removes the `MultiValueMap` nature of `HttpHeaders`, since
it inherits APIs that do not align well with underlying server
implementations. Notably, methods that allows to iterate over the whole
collection of headers are susceptible to artificially introduced
duplicates when multiple casings are used for a given header, depending
on the underlying implementation.
This change includes a dedicated key set implementation to support
iterator-based removal, and either keeps map method implementations that
are relevant or introduces header-focused methods that have a similar
responsibility (like `hasHeaderValues(String, List)` and
`containsHeaderValue(String, String)`).
In order to nudge users away from using an HttpHeaders as a Map, the
`asSingleValueMap` view is deprecated. In order to offer an escape
hatch to users that do make use of the `MultiValueMap` API, a similar
`asMultiValueMap` view is introduced but is immediately marked as
deprecated.
This change also adds map-like but header-focused assertions to
`HttpHeadersAssert`, since it cannot extend `AbstractMapAssert` anymore.
Closes gh-33913
This commit updates the whole Spring Framework codebase to use JSpecify
annotations instead of Spring null-safety annotations with JSR 305
semantics.
JSpecify provides signficant enhancements such as properly defined
specifications, a canonical dependency with no split-package issue,
better tooling, better Kotlin integration and the capability to specify
generic type, array and varargs element null-safety. Generic type
null-safety is not defined by this commit yet and will be specified
later.
A key difference is that Spring null-safety annotations, following
JSR 305 semantics, apply to fields, parameters and return values,
while JSpecify annotations apply to type usages. That's why this
commit moves nullability annotations closer to the type for fields
and return values.
See gh-28797
Prior to this commit, `MockMvc` would support checking for the Servlet
error message as the "response status reason". While this error message
can be driven with the `@ResponseStatus` annotation, this message is not
technically the HTTP status reason listed on the response status line.
This message is provided by the Servlet container in the error page when
the `response.sendError(int, String)` method is used.
This commit adds the missing
`mvc.get().uri("/error/message")).hasErrorMessage("error message")`
assertion to check for this Servlet error message.
Closes gh-34016
Sam Brannen
rstoyanchev
blake_bauman
Juergen Hoeller
Sébastien Deleuze
Dmitry Sulman
Johnny Lim
Brian Clozel
Kevin Houtz
Mengqi Xu
Yanming Zhou
Simon Baslé
Stéphane Nicoll
Sébastien Deleuze