This commit removes the JUnit 4 dependency from all modules except
spring-test which provides explicit JUnit 4 support.
This commit also includes the following.
- migration from JUnit 4 assertions to JUnit Jupiter assertions in all
Kotlin tests
- migration from JUnit 4 assumptions in Spring's TestGroup support to
JUnit Jupiter assumptions, based on org.opentest4j.TestAbortedException
- introduction of a new TestGroups utility class than can be used from
existing JUnit 4 tests in the spring-test module in order to perform
assumptions using JUnit 4's Assume class
See gh-23451
Prior to this commit, the standard Gradle `test` task was configured to
execute all JUnit tests and had a dependency on the `testNG` task. In
addition, the `aggregateTestReports` task depended on the results of
the `test` and `testNG` tasks as input. Consequently, a subsequent
execution of the `aggregateTestReports` task would not be considered
UP-TO-DATE since the JUnit and TestNG results were both written to the
same "test" reports folder.
This commit introduces a new `junit` test task that allows JUnit and
TestNG test output to be completely independent. The standard `test`
task now depends on `junit` and `testNG` but does not execute any tests
itself, and the `aggregateTestReports` task now depends on the
individual `junit` and `testNG` results instead of on the mixed `test`
results.
See also: eec183ef28
This commit upgrades Coroutines support to kotlinx.coroutines
1.3.0-RC, leverages the new Coroutines BOM and refine Coroutines
detection to avoid false positives.
Only Coroutines to Mono context interoperability is supported
for now.
CLoses gh-23326
This commit simplifies the build for spring-test by running JUnit 4
tests and JUnit Jupiter tests together in the standard Gradle `test`
task.
As an added bonus, the ignored tests in SpringJUnit4ConcurrencyTests
and ClassLevelDisabledSpringRuleTests are now reported in the test
results.
See gh-23286
The commit deprecates syncBody(Object) in favor of body(Object)
which has the same behavior in ServerResponse, WebClient and
WebTestClient. It also adds body(Object, Class) and
body(Object, ParameterizedTypeReference) methods in order to support
any reactive type that can be adapted to a Publisher via
ReactiveAdapterRegistry. Related BodyInserters#fromProducer
methods are provided as well.
Shadowed Kotlin body<T>() extensions are deprecated in favor of
bodyWithType<T>() ones, including dedicated Publisher<T> and
Flow<T> variants. Coroutines extensions are adapted as well, and
body(Object) can now be used with suspending functions.
Closes gh-23212
Prior to this commit, the three `test` tasks in the spring-test module
shared the same output directory for test reports. This had the
negative side effect of causing Gradle to believe that the tasks were
not UP-TO-DATE. Consequently, all three `test` tasks in the spring-test
module were executed for every build even if there were zero changes in
the spring-test module.
This commit fixes this issue by allowing Gradle to use the default test
results output directory for each `test` task. Thanks to @marcphilipp
for providing the tip.
In addition, the Artifactory Gradle task in the Default Job of the
Bamboo build plan for the Spring Framework (SPR-PUB) has been updated
to use the following custom test results directory pattern:
`**/build/test-results/**/*.xml`.
See: https://guides.gradle.org/using-build-cache/#concepts_overlapping_outputs
Prior to this commit, the generated POMs for Spring Framework modules
would contain unneeded/harmful information from the Spring Framework
build:
1. The BOM imports applied to each module by the dependency
management plugin, for example for Netty or Reactor Netty.
Spring should not export that opinion to its POMs.
2. The exclusion of "org.slf4:jcl-over-slf4j" from *all* dependencies,
which made the POMs much larger than necessary and suggested to
developers that they should exclude it as well when using all those
listed dependencies. In fact, only Apache Tiles currently brings that
transitively.
This commit removes that information from the POMs.
The dependencyManagement Gradle plugin is disabled for POM generation
and we manually resolve the dependency versions during the generation
phase.
The Gradle build is streamlined to exclude "org.slf4:jcl-over-slf4j"
only when necessary.
Issue: SPR-16893
Gradle 4.6 provides built-in support for the JUnit Platform within the
standard `test` task.
This commit configures a custom `testJUnitJupiter` test task for
executing JUnit Jupiter tests directly on the JUnit Platform instead of
indirectly on JUnit 4 via @RunWith(JUnitPlatform.class).
This switch provides for better integration with Gradle's test reporting
and paves the way for a possible transition to the JUnit Platform in the
future.
Issue: SPR-16672
Prior to this commit, various dependencies in the spring-test module
pulled in commons-logging as a transitive dependency. Consequently,
the presence of commons-logging in the generated Eclipse classpath
overrode the intended use of the spring-jcl module causing JUL to be
used instead of log4j for tests executed within Eclipse, thereby
ignoring the configuration in src/test/resources/log4j2-test.xml.
This commit addresses this issue by excluding commons-logging in
spring-test.gradle for all Selenium dependencies.
Issue: SPR-15930
Sam Brannen
Sebastien Deleuze
Juergen Hoeller
Sam Brannen
Brian Clozel
Rossen Stoyanchev
Violeta Georgieva