Spring/spring-framework
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix cross references

Browse Source
This commit is contained in:
Rob Winch
2023-04-19 10:26:17 -05:00
committed by rstoyanchev
parent 6b341ddf19
commit 139cde47e2
296 changed files with 1505 additions and 1505 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
framework-docs/modules/ROOT/pages/testing/annotations.adoc
View File

@@ -4,11 +4,11 @@
This section covers annotations that you can use when you test Spring applications.
It includes the following topics:
* <<integration-testing-annotations-standard>>
* <<integration-testing-annotations-spring>>
* <<integration-testing-annotations-junit4>>
* <<integration-testing-annotations-junit-jupiter>>
* <<integration-testing-annotations-meta>>
* xref:testing/annotations/integration-standard.adoc[Standard Annotation Support]
* xref:testing/annotations/integration-spring.adoc[Spring Testing Annotations]
* xref:testing/annotations/integration-junit4.adoc[Spring JUnit 4 Testing Annotations]
* xref:testing/annotations/integration-junit-jupiter.adoc[Spring JUnit Jupiter Testing Annotations]
* xref:testing/annotations/integration-meta.adoc[Meta-Annotation Support for Testing]

68
framework-docs/modules/ROOT/pages/testing/annotations/integration-junit-jupiter.adoc
View File

@@ -2,15 +2,15 @@
= Spring JUnit Jupiter Testing Annotations
The following annotations are supported when used in conjunction with the
<<testcontext-junit-jupiter-extension, `SpringExtension`>> and JUnit Jupiter
xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-extension[`SpringExtension`] and JUnit Jupiter
(that is, the programming model in JUnit 5):
* <<integration-testing-annotations-junit-jupiter-springjunitconfig>>
* <<integration-testing-annotations-junit-jupiter-springjunitwebconfig>>
* <<integration-testing-annotations-testconstructor>>
* <<integration-testing-annotations-nestedtestconfiguration>>
* <<integration-testing-annotations-junit-jupiter-enabledif>>
* <<integration-testing-annotations-junit-jupiter-disabledif>>
* xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-junit-jupiter-springjunitconfig[`@SpringJUnitConfig`]
* xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-junit-jupiter-springjunitwebconfig[`@SpringJUnitWebConfig`]
* xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-testconstructor[`@TestConstructor`]
* xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-nestedtestconfiguration[`@NestedTestConfiguration`]
* xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-junit-jupiter-enabledif[`@EnabledIf`]
* xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-junit-jupiter-disabledif[`@DisabledIf`]
[[integration-testing-annotations-junit-jupiter-springjunitconfig]]
== `@SpringJUnitConfig`
@@ -70,7 +70,7 @@ location of a configuration file:
<1> Specify the location of a configuration file.
See <<testcontext-ctx-management>> as well as the javadoc for
See xref:testing/testcontext-framework/ctx-management.adoc[Context Management] as well as the javadoc for
{api-spring-framework}/test/context/junit/jupiter/SpringJUnitConfig.html[`@SpringJUnitConfig`]
and `@ContextConfiguration` for further details.
@@ -135,7 +135,7 @@ location of a configuration file:
<1> Specify the location of a configuration file.
See <<testcontext-ctx-management>> as well as the javadoc for
See xref:testing/testcontext-framework/ctx-management.adoc[Context Management] as well as the javadoc for
{api-spring-framework}/test/context/junit/jupiter/web/SpringJUnitWebConfig.html[`@SpringJUnitWebConfig`],
{api-spring-framework}/test/context/ContextConfiguration.html[`@ContextConfiguration`], and
{api-spring-framework}/test/context/web/WebAppConfiguration.html[`@WebAppConfiguration`]
@@ -159,7 +159,7 @@ constructor takes precedence over both `@TestConstructor` and the default mode.
The default _test constructor autowire mode_ can be changed by setting the
`spring.test.constructor.autowire.mode` JVM system property to `all`. Alternatively, the
default mode may be set via the
<<appendix.adoc#appendix-spring-properties,`SpringProperties`>> mechanism.
xref:appendix.adoc#appendix-spring-properties[`SpringProperties`] mechanism.
As of Spring Framework 5.3, the default mode may also be configured as a
https://junit.org/junit5/docs/current/user-guide/#running-tests-config-params[JUnit Platform configuration parameter].
@@ -192,36 +192,36 @@ change the default mode.
The default _enclosing configuration inheritance mode_ is `INHERIT`, but it can be
changed by setting the `spring.test.enclosing.configuration` JVM system property to
`OVERRIDE`. Alternatively, the default mode may be set via the
<<appendix.adoc#appendix-spring-properties,`SpringProperties`>> mechanism.
xref:appendix.adoc#appendix-spring-properties[`SpringProperties`] mechanism.
=====
The <<testcontext-framework>> honors `@NestedTestConfiguration` semantics for the
The xref:testing/testcontext-framework.adoc[Spring TestContext Framework] honors `@NestedTestConfiguration` semantics for the
following annotations.
* <<spring-testing-annotation-bootstrapwith>>
* <<spring-testing-annotation-contextconfiguration>>
* <<spring-testing-annotation-webappconfiguration>>
* <<spring-testing-annotation-contexthierarchy>>
* <<spring-testing-annotation-activeprofiles>>
* <<spring-testing-annotation-testpropertysource>>
* <<spring-testing-annotation-dynamicpropertysource>>
* <<spring-testing-annotation-dirtiescontext>>
* <<spring-testing-annotation-testexecutionlisteners>>
* <<spring-testing-annotation-recordapplicationevents>>
* <<testcontext-tx,`@Transactional`>>
* <<spring-testing-annotation-commit>>
* <<spring-testing-annotation-rollback>>
* <<spring-testing-annotation-sql>>
* <<spring-testing-annotation-sqlconfig>>
* <<spring-testing-annotation-sqlmergemode>>
* <<integration-testing-annotations-testconstructor>>
* xref:testing/annotations/integration-spring/annotation-bootstrapwith.adoc[`@BootstrapWith`]
* xref:testing/annotations/integration-spring/annotation-contextconfiguration.adoc[`@ContextConfiguration`]
* xref:testing/annotations/integration-spring/annotation-webappconfiguration.adoc[`@WebAppConfiguration`]
* xref:testing/annotations/integration-spring/annotation-contexthierarchy.adoc[`@ContextHierarchy`]
* xref:testing/annotations/integration-spring/annotation-activeprofiles.adoc[`@ActiveProfiles`]
* xref:testing/annotations/integration-spring/annotation-testpropertysource.adoc[`@TestPropertySource`]
* xref:testing/annotations/integration-spring/annotation-dynamicpropertysource.adoc[`@DynamicPropertySource`]
* xref:testing/annotations/integration-spring/annotation-dirtiescontext.adoc[`@DirtiesContext`]
* xref:testing/annotations/integration-spring/annotation-testexecutionlisteners.adoc[`@TestExecutionListeners`]
* xref:testing/annotations/integration-spring/annotation-recordapplicationevents.adoc[`@RecordApplicationEvents`]
* xref:testing/testcontext-framework/tx.adoc[`@Transactional`]
* xref:testing/annotations/integration-spring/annotation-commit.adoc[`@Commit`]
* xref:testing/annotations/integration-spring/annotation-rollback.adoc[`@Rollback`]
* xref:testing/annotations/integration-spring/annotation-sql.adoc[`@Sql`]
* xref:testing/annotations/integration-spring/annotation-sqlconfig.adoc[`@SqlConfig`]
* xref:testing/annotations/integration-spring/annotation-sqlmergemode.adoc[`@SqlMergeMode`]
* xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-testconstructor[`@TestConstructor`]
NOTE: The use of `@NestedTestConfiguration` typically only makes sense in conjunction
with `@Nested` test classes in JUnit Jupiter; however, there may be other testing
frameworks with support for Spring and nested test classes that make use of this
annotation.
See <<testcontext-junit-jupiter-nested-test-configuration>> for an example and further
See xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-nested-test-configuration[`@Nested` test class configuration] for an example and further
details.
[[integration-testing-annotations-junit-jupiter-enabledif]]
@@ -235,9 +235,9 @@ within that class are automatically enabled by default as well.
Expressions can be any of the following:
* <<core.adoc#expressions, Spring Expression Language>> (SpEL) expression. For example:
* xref:core/expressions.adoc[Spring Expression Language] (SpEL) expression. For example:
`@EnabledIf("#{systemProperties['os.name'].toLowerCase().contains('mac')}")`
* Placeholder for a property available in the Spring <<core.adoc#beans-environment, `Environment`>>.
* Placeholder for a property available in the Spring xref:core/beans/environment.adoc[`Environment`].
For example: `@EnabledIf("${smoke.tests.enabled}")`
* Text literal. For example: `@EnabledIf("true")`
@@ -295,9 +295,9 @@ test methods within that class are automatically disabled as well.
Expressions can be any of the following:
* <<core.adoc#expressions, Spring Expression Language>> (SpEL) expression. For example:
* xref:core/expressions.adoc[Spring Expression Language] (SpEL) expression. For example:
`@DisabledIf("#{systemProperties['os.name'].toLowerCase().contains('mac')}")`
* Placeholder for a property available in the Spring <<core.adoc#beans-environment, `Environment`>>.
* Placeholder for a property available in the Spring xref:core/beans/environment.adoc[`Environment`].
For example: `@DisabledIf("${smoke.tests.disabled}")`
* Text literal. For example: `@DisabledIf("true")`

14
framework-docs/modules/ROOT/pages/testing/annotations/integration-junit4.adoc
View File

@@ -2,13 +2,13 @@
= Spring JUnit 4 Testing Annotations
The following annotations are supported only when used in conjunction with the
<<testcontext-junit4-runner, SpringRunner>>, <<testcontext-junit4-rules, Spring's JUnit 4
rules>>, or <<testcontext-support-classes-junit4, Spring's JUnit 4 support classes>>:
xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit4-runner[SpringRunner], xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit4-rules[Spring's JUnit 4 rules]
, or xref:testing/testcontext-framework/support-classes.adoc#testcontext-support-classes-junit4[Spring's JUnit 4 support classes]:
* <<integration-testing-annotations-junit4-ifprofilevalue>>
* <<integration-testing-annotations-junit4-profilevaluesourceconfiguration>>
* <<integration-testing-annotations-junit4-timed>>
* <<integration-testing-annotations-junit4-repeat>>
* xref:testing/annotations/integration-junit4.adoc#integration-testing-annotations-junit4-ifprofilevalue[`@IfProfileValue`]
* xref:testing/annotations/integration-junit4.adoc#integration-testing-annotations-junit4-profilevaluesourceconfiguration[`@ProfileValueSourceConfiguration`]
* xref:testing/annotations/integration-junit4.adoc#integration-testing-annotations-junit4-timed[`@Timed`]
* xref:testing/annotations/integration-junit4.adoc#integration-testing-annotations-junit4-repeat[`@Repeat`]
[[integration-testing-annotations-junit4-ifprofilevalue]]
== `@IfProfileValue`
@@ -154,7 +154,7 @@ times that the test method is to be run is specified in the annotation.
The scope of execution to be repeated includes execution of the test method itself as
well as any setting up or tearing down of the test fixture. When used with the
<<testcontext-junit4-rules, `SpringMethodRule`>>, the scope additionally includes
xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit4-rules[`SpringMethodRule`], the scope additionally includes
preparation of the test instance by `TestExecutionListener` implementations. The
following example shows how to use the `@Repeat` annotation:

4
framework-docs/modules/ROOT/pages/testing/annotations/integration-meta.adoc
View File

@@ -2,11 +2,11 @@
= Meta-Annotation Support for Testing
You can use most test-related annotations as
<<core.adoc#beans-meta-annotations, meta-annotations>> to create custom composed
xref:core/beans/classpath-scanning.adoc#beans-meta-annotations[meta-annotations] to create custom composed
annotations and reduce configuration duplication across a test suite.
You can use each of the following as a meta-annotation in conjunction with the
<<testcontext-framework, TestContext framework>>.
xref:testing/testcontext-framework.adoc[TestContext framework].
* `@BootstrapWith`
* `@ContextConfiguration`

36
framework-docs/modules/ROOT/pages/testing/annotations/integration-spring.adoc
View File

@@ -8,22 +8,22 @@ values, attribute aliases, and other details.
Spring's testing annotations include the following:
* <<spring-testing-annotation-bootstrapwith>>
* <<spring-testing-annotation-contextconfiguration>>
* <<spring-testing-annotation-webappconfiguration>>
* <<spring-testing-annotation-contexthierarchy>>
* <<spring-testing-annotation-activeprofiles>>
* <<spring-testing-annotation-testpropertysource>>
* <<spring-testing-annotation-dynamicpropertysource>>
* <<spring-testing-annotation-dirtiescontext>>
* <<spring-testing-annotation-testexecutionlisteners>>
* <<spring-testing-annotation-recordapplicationevents>>
* <<spring-testing-annotation-commit>>
* <<spring-testing-annotation-rollback>>
* <<spring-testing-annotation-beforetransaction>>
* <<spring-testing-annotation-aftertransaction>>
* <<spring-testing-annotation-sql>>
* <<spring-testing-annotation-sqlconfig>>
* <<spring-testing-annotation-sqlmergemode>>
* <<spring-testing-annotation-sqlgroup>>
* xref:testing/annotations/integration-spring/annotation-bootstrapwith.adoc[`@BootstrapWith`]
* xref:testing/annotations/integration-spring/annotation-contextconfiguration.adoc[`@ContextConfiguration`]
* xref:testing/annotations/integration-spring/annotation-webappconfiguration.adoc[`@WebAppConfiguration`]
* xref:testing/annotations/integration-spring/annotation-contexthierarchy.adoc[`@ContextHierarchy`]
* xref:testing/annotations/integration-spring/annotation-activeprofiles.adoc[`@ActiveProfiles`]
* xref:testing/annotations/integration-spring/annotation-testpropertysource.adoc[`@TestPropertySource`]
* xref:testing/annotations/integration-spring/annotation-dynamicpropertysource.adoc[`@DynamicPropertySource`]
* xref:testing/annotations/integration-spring/annotation-dirtiescontext.adoc[`@DirtiesContext`]
* xref:testing/annotations/integration-spring/annotation-testexecutionlisteners.adoc[`@TestExecutionListeners`]
* xref:testing/annotations/integration-spring/annotation-recordapplicationevents.adoc[`@RecordApplicationEvents`]
* xref:testing/annotations/integration-spring/annotation-commit.adoc[`@Commit`]
* xref:testing/annotations/integration-spring/annotation-rollback.adoc[`@Rollback`]
* xref:testing/annotations/integration-spring/annotation-beforetransaction.adoc[`@BeforeTransaction`]
* xref:testing/annotations/integration-spring/annotation-aftertransaction.adoc[`@AfterTransaction`]
* xref:testing/annotations/integration-spring/annotation-sql.adoc[`@Sql`]
* xref:testing/annotations/integration-spring/annotation-sqlconfig.adoc[`@SqlConfig`]
* xref:testing/annotations/integration-spring/annotation-sqlmergemode.adoc[`@SqlMergeMode`]
* xref:testing/annotations/integration-spring/annotation-sqlgroup.adoc[`@SqlGroup`]

6
framework-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-activeprofiles.adoc
View File

@@ -59,11 +59,11 @@ be active:
NOTE: `@ActiveProfiles` provides support for inheriting active bean definition profiles
declared by superclasses and enclosing classes by default. You can also resolve active
bean definition profiles programmatically by implementing a custom
<<testcontext-ctx-management-env-profiles-ActiveProfilesResolver, `ActiveProfilesResolver`>>
xref:testing/testcontext-framework/ctx-management/env-profiles.adoc#testcontext-ctx-management-env-profiles-ActiveProfilesResolver[`ActiveProfilesResolver`]
and registering it by using the `resolver` attribute of `@ActiveProfiles`.
See <<testcontext-ctx-management-env-profiles>>,
<<testcontext-junit-jupiter-nested-test-configuration>>, and the
See xref:testing/testcontext-framework/ctx-management/env-profiles.adoc[Context Configuration with Environment Profiles],
xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-nested-test-configuration[`@Nested` test class configuration], and the
{api-spring-framework}/test/context/ActiveProfiles.html[`@ActiveProfiles`] javadoc for
examples and further details.

2
framework-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-bootstrapwith.adoc
View File

@@ -4,5 +4,5 @@
`@BootstrapWith` is a class-level annotation that you can use to configure how the Spring
TestContext Framework is bootstrapped. Specifically, you can use `@BootstrapWith` to
specify a custom `TestContextBootstrapper`. See the section on
<<testcontext-bootstrapping, bootstrapping the TestContext framework>> for further details.
xref:testing/testcontext-framework/bootstrapping.adoc[bootstrapping the TestContext framework] for further details.

6
framework-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-contextconfiguration.adoc
View File

@@ -10,7 +10,7 @@ Resource locations are typically XML configuration files or Groovy scripts locat
classpath, while component classes are typically `@Configuration` classes. However,
resource locations can also refer to files and scripts in the file system, and component
classes can be `@Component` classes, `@Service` classes, and so on. See
<<testcontext-ctx-management-javaconfig-component-classes>> for further details.
xref:testing/testcontext-framework/ctx-management/javaconfig.adoc#testcontext-ctx-management-javaconfig-component-classes[null] for further details.
The following example shows a `@ContextConfiguration` annotation that refers to an XML
file:
@@ -116,7 +116,7 @@ NOTE: `@ContextConfiguration` provides support for inheriting resource locations
configuration classes as well as context initializers that are declared by superclasses
or enclosing classes.
See <<testcontext-ctx-management>>,
<<testcontext-junit-jupiter-nested-test-configuration>>, and the `@ContextConfiguration`
See xref:testing/testcontext-framework/ctx-management.adoc[Context Management],
xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-nested-test-configuration[`@Nested` test class configuration], and the `@ContextConfiguration`
javadocs for further details.

2
framework-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-contexthierarchy.adoc
View File

@@ -57,7 +57,7 @@ within a test class hierarchy):
If you need to merge or override the configuration for a given level of the context
hierarchy within a test class hierarchy, you must explicitly name that level by supplying
the same value to the `name` attribute in `@ContextConfiguration` at each corresponding
level in the class hierarchy. See <<testcontext-ctx-management-ctx-hierarchies>> and the
level in the class hierarchy. See xref:testing/testcontext-framework/ctx-management/hierarchies.adoc[Context Hierarchies] and the
{api-spring-framework}/test/context/ContextHierarchy.html[`@ContextHierarchy`] javadoc
for further examples.

2
framework-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-dynamicpropertysource.adoc
View File

@@ -55,5 +55,5 @@ The following example demonstrates how to register a dynamic property:
<2> Accept a `DynamicPropertyRegistry` as an argument.
<3> Register a dynamic `server.port` property to be retrieved lazily from the server.
See <<testcontext-ctx-management-dynamic-property-sources>> for further details.
See xref:testing/testcontext-framework/ctx-management/dynamic-property-sources.adoc[Context Configuration with Dynamic Property Sources] for further details.

2
framework-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-recordapplicationevents.adoc
View File

@@ -7,7 +7,7 @@ _Spring TestContext Framework_ to record all application events that are publish
The recorded events can be accessed via the `ApplicationEvents` API within tests.
See <<testcontext-application-events>> and the
See xref:testing/testcontext-framework/application-events.adoc[Application Events] and the
{api-spring-framework}/test/context/event/RecordApplicationEvents.html[`@RecordApplicationEvents`
javadoc] for an example and further details.

2
framework-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-rollback.adoc
View File

@@ -4,7 +4,7 @@
`@Rollback` indicates whether the transaction for a transactional test method should be
rolled back after the test method has completed. If `true`, the transaction is rolled
back. Otherwise, the transaction is committed (see also
<<spring-testing-annotation-commit>>). Rollback for integration tests in the Spring
xref:testing/annotations/integration-spring/annotation-commit.adoc[`@Commit`]). Rollback for integration tests in the Spring
TestContext Framework defaults to `true` even if `@Rollback` is not explicitly declared.
When declared as a class-level annotation, `@Rollback` defines the default rollback

2
framework-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-sql.adoc
View File

@@ -27,6 +27,6 @@ it:
----
<1> Run two scripts for this test.
See <<testcontext-executing-sql-declaratively>> for further details.
See xref:testing/testcontext-framework/executing-sql.adoc#testcontext-executing-sql-declaratively[Executing SQL scripts declaratively with @Sql] for further details.

6
framework-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-testexecutionlisteners.adoc
View File

@@ -4,7 +4,7 @@
`@TestExecutionListeners` is used to register listeners for a particular test class, its
subclasses, and its nested classes. If you wish to register a listener globally, you
should register it via the automatic discovery mechanism described in
<<testcontext-tel-config>>.
xref:testing/testcontext-framework/tel-config.adoc[`TestExecutionListener` Configuration].
The following example shows how to register two `TestExecutionListener` implementations:
@@ -33,9 +33,9 @@ The following example shows how to register two `TestExecutionListener` implemen
By default, `@TestExecutionListeners` provides support for inheriting listeners from
superclasses or enclosing classes. See
<<testcontext-junit-jupiter-nested-test-configuration>> and the
xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-nested-test-configuration[`@Nested` test class configuration] and the
{api-spring-framework}/test/context/TestExecutionListeners.html[`@TestExecutionListeners`
javadoc] for an example and further details. If you discover that you need to switch
back to using the default `TestExecutionListener` implementations, see the note
in <<testcontext-tel-config-registering-tels>>.
in xref:testing/testcontext-framework/tel-config.adoc#testcontext-tel-config-registering-tels[Registering `TestExecutionListener` Implementations].

2
framework-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-testpropertysource.adoc
View File

@@ -55,5 +55,5 @@ The following example demonstrates how to declare inlined properties:
----
<1> Declare `timezone` and `port` properties.
See <<testcontext-ctx-management-property-sources>> for examples and further details.
See xref:testing/testcontext-framework/ctx-management/property-sources.adoc[Context Configuration with Test Property Sources] for examples and further details.

2
framework-docs/modules/ROOT/pages/testing/annotations/integration-standard.adoc
View File

@@ -15,7 +15,7 @@ and can be used anywhere in the Spring Framework.
* `@PersistenceContext` (jakarta.persistence) if JPA is present
* `@PersistenceUnit` (jakarta.persistence) if JPA is present
* `@Transactional` (org.springframework.transaction.annotation)
_with <<testcontext-tx-attribute-support, limited attribute support>>_
_with xref:testing/testcontext-framework/tx.adoc#testcontext-tx-attribute-support[limited attribute support]_
.JSR-250 Lifecycle Annotations
[NOTE]

36
framework-docs/modules/ROOT/pages/testing/integration.adoc
View File

@@ -12,7 +12,7 @@ Doing so lets you test things such as:
The Spring Framework provides first-class support for integration testing in the
`spring-test` module. The name of the actual JAR file might include the release version
and might also be in the long `org.springframework.test` form, depending on where you get
it from (see the <<core.adoc#beans-dependencies, section on Dependency Management>>
it from (see the xref:core/beans/dependencies.adoc[section on Dependency Management]
for an explanation). This library includes the `org.springframework.test` package, which
contains valuable classes for integration testing with a Spring container. This testing
does not rely on an application server or other deployment environment. Such tests are
@@ -20,19 +20,19 @@ slower to run than unit tests but much faster than the equivalent Selenium tests
remote tests that rely on deployment to an application server.
Unit and integration testing support is provided in the form of the annotation-driven
<<testcontext-framework, Spring TestContext Framework>>. The TestContext framework is
xref:testing/testcontext-framework.adoc[Spring TestContext Framework]. The TestContext framework is
agnostic of the actual testing framework in use, which allows instrumentation of tests
in various environments, including JUnit, TestNG, and others.
The following section provides an overview of the high-level goals of Spring's
integration support, and the rest of this chapter then focuses on dedicated topics:
* <<integration-testing-support-jdbc>>
* <<testcontext-framework>>
* <<webtestclient>>
* <<spring-mvc-test-framework>>
* <<spring-mvc-test-client>>
* <<integration-testing-annotations>>
* xref:testing/support-jdbc.adoc[JDBC Testing Support]
* xref:testing/testcontext-framework.adoc[Spring TestContext Framework]
* xref:testing/webtestclient.adoc[WebTestClient]
* xref:testing/spring-mvc-test-framework.adoc[MockMvc]
* xref:testing/spring-mvc-test-client.adoc[Testing Client Applications]
* xref:testing/annotations.adoc[Annotations]
@@ -41,10 +41,10 @@ integration support, and the rest of this chapter then focuses on dedicated topi
Spring's integration testing support has the following primary goals:
* To manage <<testing-ctx-management, Spring IoC container caching>> between tests.
* To provide <<testing-fixture-di, Dependency Injection of test fixture instances>>.
* To provide <<testing-tx, transaction management>> appropriate to integration testing.
* To supply <<testing-support-classes, Spring-specific base classes>> that assist
* To manage xref:testing/integration.adoc#testing-ctx-management[Spring IoC container caching] between tests.
* To provide xref:testing/integration.adoc#testing-fixture-di[Dependency Injection of test fixture instances].
* To provide xref:testing/integration.adoc#testing-tx[transaction management] appropriate to integration testing.
* To supply xref:testing/integration.adoc#testing-support-classes[Spring-specific base classes] that assist
developers in writing integration tests.
The next few sections describe each goal and provide links to implementation and
@@ -78,7 +78,7 @@ reloading (for example, by modifying a bean definition or the state of an applic
object) the TestContext framework can be configured to reload the configuration and
rebuild the application context before executing the next test.
See <<testcontext-ctx-management>> and <<testcontext-ctx-management-caching>> with the
See xref:testing/testcontext-framework/ctx-management.adoc[Context Management] and xref:testing/testcontext-framework/ctx-management/caching.adoc[Context Caching] with the
TestContext framework.
@@ -105,7 +105,7 @@ integration tests that test the following areas:
perform as anticipated?
See dependency injection of test fixtures with the
<<testcontext-fixture-di, TestContext framework>>.
xref:testing/testcontext-framework/fixture-di.adoc[TestContext framework].
[[testing-tx]]
@@ -128,9 +128,9 @@ using a `PlatformTransactionManager` bean defined in the test's application cont
If you want a transaction to commit (unusual, but occasionally useful when you want a
particular test to populate or modify the database), you can tell the TestContext
framework to cause the transaction to commit instead of roll back by using the
<<integration-testing-annotations, `@Commit`>> annotation.
xref:testing/annotations.adoc[`@Commit`] annotation.
See transaction management with the <<testcontext-tx, TestContext framework>>.
See transaction management with the xref:testing/testcontext-framework/tx.adoc[TestContext framework].
[[testing-support-classes]]
@@ -147,9 +147,9 @@ which let you access:
queries to confirm database state both before and after execution of database-related
application code, and Spring ensures that such queries run in the scope of the same
transaction as the application code. When used in conjunction with an ORM tool, be sure
to avoid <<testcontext-tx-false-positives, false positives>>.
to avoid xref:testing/testcontext-framework/tx.adoc#testcontext-tx-false-positives[false positives].
In addition, you may want to create your own custom, application-wide superclass with
instance variables and methods specific to your project.
See support classes for the <<testcontext-support-classes, TestContext framework>>.
See support classes for the xref:testing/testcontext-framework/support-classes.adoc[TestContext framework].

4
framework-docs/modules/ROOT/pages/testing/introduction.adoc
View File

@@ -2,7 +2,7 @@
= Introduction to Spring Testing
Testing is an integral part of enterprise software development. This chapter focuses on
the value added by the IoC principle to <<unit-testing, unit testing>> and on the benefits
of the Spring Framework's support for <<integration-testing, integration testing>>. (A
the value added by the IoC principle to xref:testing/unit.adoc[unit testing] and on the benefits
of the Spring Framework's support for xref:testing/integration.adoc[integration testing]. (A
thorough treatment of testing in the enterprise is beyond the scope of this reference
manual.)

4
framework-docs/modules/ROOT/pages/testing/resources.adoc
View File

@@ -4,10 +4,10 @@ See the following resources for more information about testing:
* https://www.junit.org/[JUnit]: "A programmer-friendly testing framework for Java and the JVM".
Used by the Spring Framework in its test suite and supported in the
<<testcontext-framework, Spring TestContext Framework>>.
xref:testing/testcontext-framework.adoc[Spring TestContext Framework].
* https://testng.org/[TestNG]: A testing framework inspired by JUnit with added support
for test groups, data-driven testing, distributed testing, and other features. Supported
in the <<testcontext-framework, Spring TestContext Framework>>
in the xref:testing/testcontext-framework.adoc[Spring TestContext Framework]
* https://assertj.github.io/doc/[AssertJ]: "Fluent assertions for Java",
including support for Java 8 lambdas, streams, and numerous other features.
* https://en.wikipedia.org/wiki/Mock_Object[Mock Objects]: Article in Wikipedia.

2
framework-docs/modules/ROOT/pages/testing/spring-mvc-test-framework.adoc
View File

@@ -6,7 +6,7 @@ MVC applications. It performs full Spring MVC request handling but via mock requ
response objects instead of a running server.
MockMvc can be used on its own to perform requests and verify responses. It can also be
used through the <<webtestclient>> where MockMvc is plugged in as the server to handle
used through the xref:testing/webtestclient.adoc[WebTestClient] where MockMvc is plugged in as the server to handle
requests with. The advantage of `WebTestClient` is the option to work with higher level
objects instead of raw data as well as the ability to switch to full, end-to-end HTTP
tests against a live server and use the same test API.

4
framework-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/async-requests.adoc
View File

@@ -2,11 +2,11 @@
= Async Requests
This section shows how to use MockMvc on its own to test asynchronous request handling.
If using MockMvc through the <<webtestclient>>, there is nothing special to do to make
If using MockMvc through the xref:testing/webtestclient.adoc[WebTestClient], there is nothing special to do to make
asynchronous requests work as the `WebTestClient` automatically does what is described
in this section.
Servlet asynchronous requests, <<web.adoc#mvc-ann-async,supported in Spring MVC>>,
Servlet asynchronous requests, xref:web/webmvc/mvc-ann-async.adoc[supported in Spring MVC],
work by exiting the Servlet container thread and allowing the application to compute
the response asynchronously, after which an async dispatch is made to complete
processing on a Servlet container thread.

2
framework-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-htmlunit.adoc
View File

@@ -1,7 +1,7 @@
[[spring-mvc-test-server-htmlunit]]
= HtmlUnit Integration
Spring provides integration between <<spring-mvc-test-server, MockMvc>> and
Spring provides integration between xref:testing/spring-mvc-test-framework/server.adoc[MockMvc] and
https://htmlunit.sourceforge.io/[HtmlUnit]. This simplifies performing end-to-end testing
when using HTML-based views. This integration lets you:

6
framework-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-htmlunit/geb.adoc
View File

@@ -8,7 +8,7 @@ use https://www.gebish.org/[Geb] to make our tests even Groovy-er.
== Why Geb and MockMvc?
Geb is backed by WebDriver, so it offers many of the
<<spring-mvc-test-server-htmlunit-webdriver-why, same benefits>> that we get from
xref:testing/spring-mvc-test-framework/server-htmlunit/webdriver.adoc#spring-mvc-test-server-htmlunit-webdriver-why[same benefits] that we get from
WebDriver. However, Geb makes things even easier by taking care of some of the
boilerplate code for us.
@@ -28,7 +28,7 @@ def setup() {
----
NOTE: This is a simple example of using `MockMvcHtmlUnitDriverBuilder`. For more advanced
usage, see <<spring-mvc-test-server-htmlunit-webdriver-advanced-builder>>.
usage, see xref:testing/spring-mvc-test-framework/server-htmlunit/webdriver.adoc#spring-mvc-test-server-htmlunit-webdriver-advanced-builder[Advanced `MockMvcHtmlUnitDriverBuilder`].
This ensures that any URL referencing `localhost` as the server is directed to our
`MockMvc` instance without the need for a real HTTP connection. Any other URL is
@@ -62,7 +62,7 @@ forwarded to the current page object. This removes a lot of the boilerplate code
needed when using WebDriver directly.
As with direct WebDriver usage, this improves on the design of our
<<spring-mvc-test-server-htmlunit-mah-usage, HtmlUnit test>> by using the Page Object
xref:testing/spring-mvc-test-framework/server-htmlunit/mah.adoc#spring-mvc-test-server-htmlunit-mah-usage[HtmlUnit test] by using the Page Object
Pattern. As mentioned previously, we can use the Page Object Pattern with HtmlUnit and
WebDriver, but it is even easier with Geb. Consider our new Groovy-based
`CreateMessagePage` implementation:

8
framework-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-htmlunit/mah.adoc
View File

@@ -41,7 +41,7 @@ We can easily create an HtmlUnit `WebClient` that integrates with MockMvc by usi
----
NOTE: This is a simple example of using `MockMvcWebClientBuilder`. For advanced usage,
see <<spring-mvc-test-server-htmlunit-mah-advanced-builder>>.
see xref:testing/spring-mvc-test-framework/server-htmlunit/mah.adoc#spring-mvc-test-server-htmlunit-mah-advanced-builder[Advanced `MockMvcWebClientBuilder`].
This ensures that any URL that references `localhost` as the server is directed to our
`MockMvc` instance without the need for a real HTTP connection. Any other URL is
@@ -68,7 +68,7 @@ message with the following:
----
NOTE: The default context path is `""`. Alternatively, we can specify the context path,
as described in <<spring-mvc-test-server-htmlunit-mah-advanced-builder>>.
as described in xref:testing/spring-mvc-test-framework/server-htmlunit/mah.adoc#spring-mvc-test-server-htmlunit-mah-advanced-builder[Advanced `MockMvcWebClientBuilder`].
Once we have a reference to the `HtmlPage`, we can then fill out the form and submit it
to create a message, as the following example shows:
@@ -123,7 +123,7 @@ assertions use the https://assertj.github.io/doc/[AssertJ] library:
----
The preceding code improves on our
<<spring-mvc-test-server-htmlunit-mock-mvc-test, MockMvc test>> in a number of ways.
xref:testing/spring-mvc-test-framework/server-htmlunit/why.adoc#spring-mvc-test-server-htmlunit-mock-mvc-test[MockMvc test] in a number of ways.
First, we no longer have to explicitly verify our form and then create a request that
looks like the form. Instead, we request the form, fill it out, and submit it, thereby
significantly reducing the overhead.
@@ -238,5 +238,5 @@ This is more verbose, but, by building the `WebClient` with a `MockMvc` instance
the full power of MockMvc at our fingertips.
TIP: For additional information on creating a `MockMvc` instance, see
<<spring-mvc-test-server-setup-options>>.
xref:testing/spring-mvc-test-framework/server-setup-options.adoc[Setup Choices].

8
framework-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-htmlunit/webdriver.adoc
View File

@@ -180,7 +180,7 @@ We can easily create a Selenium WebDriver that integrates with MockMvc by using
----
NOTE: This is a simple example of using `MockMvcHtmlUnitDriverBuilder`. For more advanced
usage, see <<spring-mvc-test-server-htmlunit-webdriver-advanced-builder>>.
usage, see xref:testing/spring-mvc-test-framework/server-htmlunit/webdriver.adoc#spring-mvc-test-server-htmlunit-webdriver-advanced-builder[Advanced `MockMvcHtmlUnitDriverBuilder`].
The preceding example ensures that any URL that references `localhost` as the server is
directed to our `MockMvc` instance without the need for a real HTTP connection. Any other
@@ -226,9 +226,9 @@ We can then fill out the form and submit it to create a message, as follows:
----
--
This improves on the design of our <<spring-mvc-test-server-htmlunit-mah-usage, HtmlUnit test>>
This improves on the design of our xref:testing/spring-mvc-test-framework/server-htmlunit/mah.adoc#spring-mvc-test-server-htmlunit-mah-usage[HtmlUnit test]
by leveraging the Page Object Pattern. As we mentioned in
<<spring-mvc-test-server-htmlunit-webdriver-why>>, we can use the Page Object Pattern
xref:testing/spring-mvc-test-framework/server-htmlunit/webdriver.adoc#spring-mvc-test-server-htmlunit-webdriver-why[Why WebDriver and MockMvc?], we can use the Page Object Pattern
with HtmlUnit, but it is much easier with WebDriver. Consider the following
`CreateMessagePage` implementation:
@@ -499,5 +499,5 @@ This is more verbose, but, by building the `WebDriver` with a `MockMvc` instance
the full power of MockMvc at our fingertips.
TIP: For additional information on creating a `MockMvc` instance, see
<<spring-mvc-test-server-setup-options>>.
xref:testing/spring-mvc-test-framework/server-setup-options.adoc[Setup Choices].

6
framework-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-htmlunit/why.adoc
View File

@@ -177,11 +177,11 @@ with HtmlUnit.`"
You have a number of options when you want to integrate MockMvc with HtmlUnit:
* <<spring-mvc-test-server-htmlunit-mah,MockMvc and HtmlUnit>>: Use this option if you
* xref:testing/spring-mvc-test-framework/server-htmlunit/mah.adoc[MockMvc and HtmlUnit]: Use this option if you
want to use the raw HtmlUnit libraries.
* <<spring-mvc-test-server-htmlunit-webdriver,MockMvc and WebDriver>>: Use this option to
* xref:testing/spring-mvc-test-framework/server-htmlunit/webdriver.adoc[MockMvc and WebDriver]: Use this option to
ease development and reuse code between integration and end-to-end testing.
* <<spring-mvc-test-server-htmlunit-geb,MockMvc and Geb>>: Use this option if you want to
* xref:testing/spring-mvc-test-framework/server-htmlunit/geb.adoc[MockMvc and Geb]: Use this option if you want to
use Groovy for testing, ease development, and reuse code between integration and
end-to-end testing.

2
framework-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-performing-requests.adoc
View File

@@ -3,7 +3,7 @@
This section shows how to use MockMvc on its own to perform requests and verify responses.
If using MockMvc through the `WebTestClient` please see the corresponding section on
<<webtestclient-tests>> instead.
xref:testing/webtestclient.adoc#webtestclient-tests[Writing Tests] instead.
To perform requests that use any HTTP method, as the following example shows:

4
framework-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-setup-options.adoc
View File

@@ -42,7 +42,7 @@ To set up MockMvc for testing a specific controller, use the following:
----
Or you can also use this setup when testing through the
<<webtestclient-controller-config, WebTestClient>> which delegates to the same builder
xref:testing/webtestclient.adoc#webtestclient-controller-config[WebTestClient] which delegates to the same builder
as shown above.
To set up MockMvc through Spring configuration, use the following:
@@ -84,7 +84,7 @@ To set up MockMvc through Spring configuration, use the following:
----
Or you can also use this setup when testing through the
<<webtestclient-context-config, WebTestClient>> which delegates to the same builder
xref:testing/webtestclient.adoc#webtestclient-context-config[WebTestClient] which delegates to the same builder
as shown above.

2
framework-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-static-imports.adoc
View File

@@ -11,7 +11,7 @@ When using MockMvc directly to perform requests, you'll need static imports for:
An easy way to remember that is search for `MockMvc*`. If using Eclipse be sure to also
add the above as "`favorite static members`" in the Eclipse preferences.
When using MockMvc through the <<webtestclient>> you do not need static imports.
When using MockMvc through the xref:testing/webtestclient.adoc[WebTestClient] you do not need static imports.
The `WebTestClient` provides a fluent API without static imports.

4
framework-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server.adoc
View File

@@ -10,14 +10,14 @@ do they involve any of the supporting `@InitBinder`, `@ModelAttribute`, or
The Spring MVC Test framework, also known as `MockMvc`, aims to provide more complete
testing for Spring MVC controllers without a running server. It does that by invoking
the `DispatcherServlet` and passing
<<mock-objects-servlet, "`mock`" implementations of the Servlet API>> from the
xref:testing/unit.adoc#mock-objects-servlet["`mock`" implementations of the Servlet API] from the
`spring-test` module which replicates the full Spring MVC request handling without
a running server.
MockMvc is a server side test framework that lets you verify most of the functionality
of a Spring MVC application using lightweight and targeted tests. You can use it on
its own to perform requests and to verify responses, or you can also use it through
the <<webtestclient>> API with MockMvc plugged in as the server to handle requests
the xref:testing/webtestclient.adoc[WebTestClient] API with MockMvc plugged in as the server to handle requests
with.

8
framework-docs/modules/ROOT/pages/testing/support-jdbc.adoc
View File

@@ -19,8 +19,8 @@ methods.
[TIP]
====
<<testcontext-support-classes-junit4, `AbstractTransactionalJUnit4SpringContextTests`>>
and <<testcontext-support-classes-testng, `AbstractTransactionalTestNGSpringContextTests`>>
xref:testing/testcontext-framework/support-classes.adoc#testcontext-support-classes-junit4[`AbstractTransactionalJUnit4SpringContextTests`]
and xref:testing/testcontext-framework/support-classes.adoc#testcontext-support-classes-testng[`AbstractTransactionalTestNGSpringContextTests`]
provide convenience methods that delegate to the aforementioned methods in
`JdbcTestUtils`.
====
@@ -30,6 +30,6 @@ provide convenience methods that delegate to the aforementioned methods in
The `spring-jdbc` module provides support for configuring and launching an embedded
database, which you can use in integration tests that interact with a database.
For details, see <<data-access.adoc#jdbc-embedded-database-support, Embedded Database
Support>> and <<data-access.adoc#jdbc-embedded-database-dao-testing, Testing Data Access
For details, see xref:data-access/jdbc/embedded-database-support.adoc[Embedded Database Support]
and <<data-access.adoc#jdbc-embedded-database-dao-testing, Testing Data Access
Logic with an Embedded Database>>.

8
framework-docs/modules/ROOT/pages/testing/testcontext-framework.adoc
View File

@@ -17,9 +17,9 @@ required to extend a particular class hierarchy, such as the `abstract` support
The following section provides an overview of the internals of the TestContext framework.
If you are interested only in using the framework and are not interested in extending it
with your own custom listeners or custom loaders, feel free to go directly to the
configuration (<<testcontext-ctx-management, context management>>,
<<testcontext-fixture-di, dependency injection>>, <<testcontext-tx,transaction
management>>), <<testcontext-support-classes, support classes>>, and
<<integration-testing-annotations, annotation support>> sections.
configuration (xref:testing/testcontext-framework/ctx-management.adoc[context management],
xref:testing/testcontext-framework/fixture-di.adoc[dependency injection], xref:testing/testcontext-framework/tx.adoc[transaction management]
), xref:testing/testcontext-framework/support-classes.adoc[support classes], and
xref:testing/annotations.adoc[annotation support] sections.

8
framework-docs/modules/ROOT/pages/testing/testcontext-framework/aot.adoc
View File

@@ -4,7 +4,7 @@
This chapter covers Spring's Ahead of Time (AOT) support for integration tests using the
Spring TestContext Framework.
The testing support extends Spring's <<core.adoc#core.aot,core AOT support>> with the
The testing support extends Spring's xref:core/aot.adoc[core AOT support] with the
following features.
* Build-time detection of all integration tests in the current project that use the
@@ -14,10 +14,10 @@ following features.
testing annotations -- as long as the tests are run using a JUnit Platform
`TestEngine` that is registered for the current project.
* Build-time AOT processing: each unique test `ApplicationContext` in the current project
will be <<core.adoc#core.aot.refresh,refreshed for AOT processing>>.
will be xref:core/aot.adoc#core.aot.refresh[refreshed for AOT processing].
* Runtime AOT support: when executing in AOT runtime mode, a Spring integration test will
use an AOT-optimized `ApplicationContext` that participates transparently with the
<<testcontext-ctx-management-caching, context cache>>.
xref:testing/testcontext-framework/ctx-management/caching.adoc[context cache].
[WARNING]
====
@@ -35,7 +35,7 @@ the following options.
via {api-spring-framework}/context/annotation/ImportRuntimeHints.html[`@ImportRuntimeHints`].
* Annotate a test class with {api-spring-framework}/aot/hint/annotation/Reflective.html[`@Reflective`] or
{api-spring-framework}/aot/hint/annotation/RegisterReflectionForBinding.html[`@RegisterReflectionForBinding`].
* See <<core.adoc#core.aot.hints,Runtime Hints>> for details on Spring's core runtime hints
* See xref:core/aot.adoc#core.aot.hints[Runtime Hints] for details on Spring's core runtime hints
and annotation support.
[TIP]

6
framework-docs/modules/ROOT/pages/testing/testcontext-framework/application-events.adoc
View File

@@ -2,7 +2,7 @@
= Application Events
Since Spring Framework 5.3.3, the TestContext framework provides support for recording
<<core.adoc#context-functionality-events, application events>> published in the
xref:core/beans/context-introduction.adoc#context-functionality-events[application events] published in the
`ApplicationContext` so that assertions can be performed against those events within
tests. All events published during the execution of a single test are made available via
the `ApplicationEvents` API which allows you to process the events as a
@@ -11,7 +11,7 @@ the `ApplicationEvents` API which allows you to process the events as a
To use `ApplicationEvents` in your tests, do the following.
* Ensure that your test class is annotated or meta-annotated with
<<spring-testing-annotation-recordapplicationevents>>.
xref:testing/annotations/integration-spring/annotation-recordapplicationevents.adoc[`@RecordApplicationEvents`].
* Ensure that the `ApplicationEventsTestExecutionListener` is registered. Note, however,
that `ApplicationEventsTestExecutionListener` is registered by default and only needs
to be manually registered if you have custom configuration via
@@ -19,7 +19,7 @@ To use `ApplicationEvents` in your tests, do the following.
* Annotate a field of type `ApplicationEvents` with `@Autowired` and use that instance of
`ApplicationEvents` in your test and lifecycle methods (such as `@BeforeEach` and
`@AfterEach` methods in JUnit Jupiter).
** When using the <<testcontext-junit-jupiter-extension>>, you may declare a method
** When using the xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-extension[SpringExtension for JUnit Jupiter], you may declare a method
parameter of type `ApplicationEvents` in a test or lifecycle method as an alternative
to an `@Autowired` field in the test class.

26
framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management.adoc
View File

@@ -80,7 +80,7 @@ the web application context into your test, as follows:
Dependency injection by using `@Autowired` is provided by the
`DependencyInjectionTestExecutionListener`, which is configured by default
(see <<testcontext-fixture-di>>).
(see xref:testing/testcontext-framework/fixture-di.adoc[Dependency Injection of Test Fixtures]).
=====
Test classes that use the TestContext framework do not need to extend any particular
@@ -98,16 +98,16 @@ component classes (typically `@Configuration` classes), or context initializers.
Alternatively, you can implement and configure your own custom `SmartContextLoader` for
advanced use cases.
* <<testcontext-ctx-management-xml>>
* <<testcontext-ctx-management-groovy>>
* <<testcontext-ctx-management-javaconfig>>
* <<testcontext-ctx-management-mixed-config>>
* <<testcontext-ctx-management-initializers>>
* <<testcontext-ctx-management-inheritance>>
* <<testcontext-ctx-management-env-profiles>>
* <<testcontext-ctx-management-property-sources>>
* <<testcontext-ctx-management-dynamic-property-sources>>
* <<testcontext-ctx-management-web>>
* <<testcontext-ctx-management-caching>>
* <<testcontext-ctx-management-ctx-hierarchies>>
* xref:testing/testcontext-framework/ctx-management/xml.adoc[Context Configuration with XML resources]
* xref:testing/testcontext-framework/ctx-management/groovy.adoc[Context Configuration with Groovy Scripts]
* xref:testing/testcontext-framework/ctx-management/javaconfig.adoc[Context Configuration with Component Classes]
* xref:testing/testcontext-framework/ctx-management/mixed-config.adoc[Mixing XML, Groovy Scripts, and Component Classes]
* xref:testing/testcontext-framework/ctx-management/initializers.adoc[Context Configuration with Context Initializers]
* xref:testing/testcontext-framework/ctx-management/inheritance.adoc[Context Configuration Inheritance]
* xref:testing/testcontext-framework/ctx-management/env-profiles.adoc[Context Configuration with Environment Profiles]
* xref:testing/testcontext-framework/ctx-management/property-sources.adoc[Context Configuration with Test Property Sources]
* xref:testing/testcontext-framework/ctx-management/dynamic-property-sources.adoc[Context Configuration with Dynamic Property Sources]
* xref:testing/testcontext-framework/ctx-management/web.adoc[Loading a `WebApplicationContext`]
* xref:testing/testcontext-framework/ctx-management/caching.adoc[Context Caching]
* xref:testing/testcontext-framework/ctx-management/hierarchies.adoc[Context Hierarchies]

8
framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/caching.adoc
View File

@@ -60,7 +60,7 @@ maximum size is reached, a least recently used (LRU) eviction policy is used to
close stale contexts. You can configure the maximum size from the command line or a build
script by setting a JVM system property named `spring.test.context.cache.maxSize`. As an
alternative, you can set the same property via the
<<appendix.adoc#appendix-spring-properties,`SpringProperties`>> mechanism.
xref:appendix.adoc#appendix-spring-properties[`SpringProperties`] mechanism.
Since having a large number of application contexts loaded within a given test suite can
cause the suite to take an unnecessarily long time to run, it is often beneficial to
@@ -71,8 +71,8 @@ the underlying context cache, you can set the log level for the
In the unlikely case that a test corrupts the application context and requires reloading
(for example, by modifying a bean definition or the state of an application object), you
can annotate your test class or test method with `@DirtiesContext` (see the discussion of
`@DirtiesContext` in <<spring-testing-annotation-dirtiescontext, Spring Testing
Annotations>>). This instructs Spring to remove the context from the cache and rebuild
`@DirtiesContext` in xref:testing/annotations/integration-spring/annotation-dirtiescontext.adoc[Spring Testing Annotations]
). This instructs Spring to remove the context from the cache and rebuild
the application context before running the next test that requires the same application
context. Note that support for the `@DirtiesContext` annotation is provided by the
`DirtiesContextBeforeModesTestExecutionListener` and the
@@ -96,7 +96,7 @@ class is being prepared -- for example, to perform dependency injection into `@A
fields of the test instance. This means that any console logging triggered during the
initialization of the `ApplicationContext` typically cannot be associated with an
individual test method. However, if the context is closed immediately before the
execution of a test method according to <<spring-testing-annotation-dirtiescontext>>
execution of a test method according to xref:testing/annotations/integration-spring/annotation-dirtiescontext.adoc[`@DirtiesContext`]
semantics, a new instance of the context will be loaded just prior to execution of the
test method. In the latter scenario, an IDE or build tool may potentially associate
console logging with the individual test method.

4
framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/dynamic-property-sources.adoc
View File

@@ -16,7 +16,7 @@ Spring integration tests. However, this feature may also be used with any form o
external resource whose lifecycle is maintained outside the test's `ApplicationContext`.
====
In contrast to the <<testcontext-ctx-management-property-sources,`@TestPropertySource`>>
In contrast to the xref:testing/testcontext-framework/ctx-management/property-sources.adoc[`@TestPropertySource`]
annotation that is applied at the class level, `@DynamicPropertySource` must be applied
to a `static` method that accepts a single `DynamicPropertyRegistry` argument which is
used to add _name-value_ pairs to the `Environment`. Values are dynamic and provided via
@@ -33,7 +33,7 @@ abstraction or injected directly into Spring-managed components – for example,
====
If you use `@DynamicPropertySource` in a base class and discover that tests in subclasses
fail because the dynamic properties change between subclasses, you may need to annotate
your base class with <<spring-testing-annotation-dirtiescontext, `@DirtiesContext`>> to
your base class with xref:testing/annotations/integration-spring/annotation-dirtiescontext.adoc[`@DirtiesContext`] to
ensure that each subclass gets its own `ApplicationContext` with the correct dynamic
properties.
====

2
framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/env-profiles.adoc
View File

@@ -331,7 +331,7 @@ following example, the declaration of `@ActiveProfiles` (as well as other annota
has been moved to an abstract superclass, `AbstractIntegrationTest`:
NOTE: As of Spring Framework 5.3, test configuration may also be inherited from enclosing
classes. See <<testcontext-junit-jupiter-nested-test-configuration>> for details.
classes. See xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-nested-test-configuration[`@Nested` test class configuration] for details.
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java

4
framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/groovy.adoc
View File

@@ -2,11 +2,11 @@
= Context Configuration with Groovy Scripts
To load an `ApplicationContext` for your tests by using Groovy scripts that use the
<<core.adoc#groovy-bean-definition-dsl, Groovy Bean Definition DSL>>, you can annotate
xref:core/beans/basics.adoc#groovy-bean-definition-dsl[Groovy Bean Definition DSL], you can annotate
your test class with `@ContextConfiguration` and configure the `locations` or `value`
attribute with an array that contains the resource locations of Groovy scripts. Resource
lookup semantics for Groovy scripts are the same as those described for
<<testcontext-ctx-management-xml, XML configuration files>>.
xref:testing/testcontext-framework/ctx-management/xml.adoc[XML configuration files].
.Enabling Groovy script support
TIP: Support for using Groovy scripts to load an `ApplicationContext` in the Spring

2
framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/hierarchies.adoc
View File

@@ -212,7 +212,7 @@ shows this configuration scenario:
NOTE: If you use `@DirtiesContext` in a test whose context is configured as part of a
context hierarchy, you can use the `hierarchyMode` flag to control how the context cache
is cleared. For further details, see the discussion of `@DirtiesContext` in
<<spring-testing-annotation-dirtiescontext, Spring Testing Annotations>> and the
xref:testing/annotations/integration-spring/annotation-dirtiescontext.adoc[Spring Testing Annotations] and the
{api-spring-framework}/test/annotation/DirtiesContext.html[`@DirtiesContext`] javadoc.
--

2
framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/inheritance.adoc
View File

@@ -18,7 +18,7 @@ initializers, respectively, for the test class shadow and effectively replace th
configuration defined by superclasses.
NOTE: As of Spring Framework 5.3, test configuration may also be inherited from enclosing
classes. See <<testcontext-junit-jupiter-nested-test-configuration>> for details.
classes. See xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-nested-test-configuration[`@Nested` test class configuration] for details.
In the next example, which uses XML resource locations, the `ApplicationContext` for
`ExtendedTest` is loaded from `base-config.xml` and `extended-config.xml`, in that order.

2
framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/javaconfig.adoc
View File

@@ -2,7 +2,7 @@
= Context Configuration with Component Classes
To load an `ApplicationContext` for your tests by using component classes (see
<<core.adoc#beans-java, Java-based container configuration>>), you can annotate your test
xref:core/beans/java.adoc[Java-based container configuration]), you can annotate your test
class with `@ContextConfiguration` and configure the `classes` attribute with an array
that contains references to component classes. The following example shows how to do so:

4
framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/property-sources.adoc
View File

@@ -137,7 +137,7 @@ declaratively by using `@PropertySource` or programmatically. Thus, test propert
be used to selectively override properties loaded from system and application property
sources. Furthermore, inlined properties have higher precedence than properties loaded
from resource locations. Note, however, that properties registered via
<<testcontext-ctx-management-dynamic-property-sources, `@DynamicPropertySource`>> have
xref:testing/testcontext-framework/ctx-management/dynamic-property-sources.adoc[`@DynamicPropertySource`] have
higher precedence than those loaded via `@TestPropertySource`.
In the next example, the `timezone` and `port` properties and any properties defined in
@@ -191,7 +191,7 @@ set to `false`, the locations or inlined properties, respectively, for the test
shadow and effectively replace the configuration defined by superclasses.
NOTE: As of Spring Framework 5.3, test configuration may also be inherited from enclosing
classes. See <<testcontext-junit-jupiter-nested-test-configuration>> for details.
classes. See xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-nested-test-configuration[`@Nested` test class configuration] for details.
In the next example, the `ApplicationContext` for `BaseTest` is loaded by using only the
`base.properties` file as a test property source. In contrast, the `ApplicationContext`

2
framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/web-mocks.adoc
View File

@@ -3,7 +3,7 @@
To provide comprehensive web testing support, the TestContext framework has a
`ServletTestExecutionListener` that is enabled by default. When testing against a
`WebApplicationContext`, this <<testcontext-key-abstractions, `TestExecutionListener`>>
`WebApplicationContext`, this xref:testing/testcontext-framework/key-abstractions.adoc[`TestExecutionListener`]
sets up default thread-local state by using Spring Web's `RequestContextHolder` before
each test method and creates a `MockHttpServletRequest`, a `MockHttpServletResponse`, and
a `ServletWebRequest` based on the base resource path configured with

18
framework-docs/modules/ROOT/pages/testing/testcontext-framework/executing-sql.adoc
View File

@@ -5,9 +5,9 @@ When writing integration tests against a relational database, it is often benefi
run SQL scripts to modify the database schema or insert test data into tables. The
`spring-jdbc` module provides support for _initializing_ an embedded or existing database
by executing SQL scripts when the Spring `ApplicationContext` is loaded. See
<<data-access.adoc#jdbc-embedded-database-support, Embedded database support>> and
<<data-access.adoc#jdbc-embedded-database-dao-testing, Testing data access logic with an
embedded database>> for details.
xref:data-access/jdbc/embedded-database-support.adoc[Embedded database support] and
xref:data-access/jdbc/embedded-database-support.adoc#jdbc-embedded-database-dao-testing[Testing data access logic with an embedded database]
for details.
Although it is very useful to initialize a database for testing _once_ when the
`ApplicationContext` is loaded, sometimes it is essential to be able to modify the
@@ -77,8 +77,8 @@ specifies SQL scripts for a test schema and test data, sets the statement separa
Note that `ResourceDatabasePopulator` internally delegates to `ScriptUtils` for parsing
and running SQL scripts. Similarly, the `executeSqlScript(..)` methods in
<<testcontext-support-classes-junit4, `AbstractTransactionalJUnit4SpringContextTests`>>
and <<testcontext-support-classes-testng, `AbstractTransactionalTestNGSpringContextTests`>>
xref:testing/testcontext-framework/support-classes.adoc#testcontext-support-classes-junit4[`AbstractTransactionalJUnit4SpringContextTests`]
and xref:testing/testcontext-framework/support-classes.adoc#testcontext-support-classes-testng[`AbstractTransactionalTestNGSpringContextTests`]
internally use a `ResourceDatabasePopulator` to run SQL scripts. See the Javadoc for the
various `executeSqlScript(..)` methods for further details.
@@ -95,7 +95,7 @@ run against a given database before or after an integration test method. Support
NOTE: Method-level `@Sql` declarations override class-level declarations by default. As
of Spring Framework 5.2, however, this behavior may be configured per test class or per
test method via `@SqlMergeMode`. See
<<testcontext-executing-sql-declaratively-script-merging>> for further details.
xref:testing/testcontext-framework/executing-sql.adoc#testcontext-executing-sql-declaratively-script-merging[Merging and Overriding Configuration with `@SqlMergeMode`] for further details.
[[testcontext-executing-sql-declaratively-script-resources]]
=== Path Resource Semantics
@@ -382,7 +382,7 @@ that uses JUnit Jupiter and transactional tests with `@Sql`:
Note that there is no need to clean up the database after the `usersTest()` method is
run, since any changes made to the database (either within the test method or within the
`/test-data.sql` script) are automatically rolled back by the
`TransactionalTestExecutionListener` (see <<testcontext-tx,transaction management>> for
`TransactionalTestExecutionListener` (see xref:testing/testcontext-framework/tx.adoc[transaction management] for
details).
[[testcontext-executing-sql-declaratively-script-merging]]
@@ -394,7 +394,7 @@ database schema or some common test data once per test class and then provide ad
use case specific test data per test method. To enable `@Sql` merging, annotate either
your test class or test method with `@SqlMergeMode(MERGE)`. To disable merging for a
specific test method (or specific test subclass), you can switch back to the default mode
via `@SqlMergeMode(OVERRIDE)`. Consult the <<spring-testing-annotation-sqlmergemode,
`@SqlMergeMode` annotation documentation section>> for examples and further details.
via `@SqlMergeMode(OVERRIDE)`. Consult the xref:testing/annotations/integration-spring/annotation-sqlmergemode.adoc[`@SqlMergeMode` annotation documentation section]
for examples and further details.

8
framework-docs/modules/ROOT/pages/testing/testcontext-framework/fixture-di.adoc
View File

@@ -7,7 +7,7 @@ application context that you configured with `@ContextConfiguration` or related
annotations. You may use setter injection, field injection, or both, depending on
which annotations you choose and whether you place them on setter methods or fields.
If you are using JUnit Jupiter you may also optionally use constructor injection
(see <<testcontext-junit-jupiter-di>>). For consistency with Spring's annotation-based
(see xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-di[Dependency Injection with `SpringExtension`]). For consistency with Spring's annotation-based
injection support, you may also use Spring's `@Autowired` annotation or the `@Inject`
annotation from JSR-330 for field and setter injection.
@@ -20,8 +20,8 @@ actually quite natural in test code. The rationale for the difference is that yo
never instantiate your test class directly. Consequently, there is no need to be able to
invoke a `public` constructor or setter method on your test class.
Because `@Autowired` is used to perform <<core.adoc#beans-factory-autowire, autowiring by
type>>, if you have multiple bean definitions of the same type, you cannot rely on this
Because `@Autowired` is used to perform xref:core/beans/dependencies/factory-autowire.adoc[autowiring by type]
, if you have multiple bean definitions of the same type, you cannot rely on this
approach for those particular beans. In that case, you can use `@Autowired` in
conjunction with `@Qualifier`. You can also choose to use `@Inject` in conjunction with
`@Named`. Alternatively, if your test class has access to its `ApplicationContext`, you
@@ -35,7 +35,7 @@ dependency injection altogether by explicitly configuring your class with
from the list of listeners.
Consider the scenario of testing a `HibernateTitleRepository` class, as outlined in the
<<integration-testing-goals, Goals>> section. The next two code listings demonstrate the
xref:testing/integration.adoc#integration-testing-goals[Goals] section. The next two code listings demonstrate the
use of `@Autowired` on fields and setter methods. The application context configuration
is presented after all sample code listings.

2
framework-docs/modules/ROOT/pages/testing/testcontext-framework/key-abstractions.adoc
View File

@@ -40,7 +40,7 @@ responsible for managing a single `TestContext` and signaling events to each reg
== `TestExecutionListener`
`TestExecutionListener` defines the API for reacting to test-execution events published by
the `TestContextManager` with which the listener is registered. See <<testcontext-tel-config>>.
the `TestContextManager` with which the listener is registered. See xref:testing/testcontext-framework/tel-config.adoc[`TestExecutionListener` Configuration].
[[context-loaders]]
== Context Loaders

2
framework-docs/modules/ROOT/pages/testing/testcontext-framework/parallel-test-execution.adoc
View File

@@ -34,7 +34,7 @@ This may be due to the use of `@DirtiesContext` or due to automatic eviction fro
`ContextCache`. If `@DirtiesContext` is the culprit, you either need to find a way to
avoid using `@DirtiesContext` or exclude such tests from parallel execution. If the
maximum size of the `ContextCache` has been exceeded, you can increase the maximum size
of the cache. See the discussion on <<testcontext-ctx-management-caching, context caching>>
of the cache. See the discussion on xref:testing/testcontext-framework/ctx-management/caching.adoc[context caching]
for details.
====

34
framework-docs/modules/ROOT/pages/testing/testcontext-framework/support-classes.adoc
View File

@@ -15,7 +15,7 @@ loading application contexts, dependency injection of test instances, transactio
method execution, and so on. If you want to use the Spring TestContext Framework with an
alternative runner (such as JUnit 4's `Parameterized` runner) or third-party runners
(such as the `MockitoJUnitRunner`), you can, optionally, use
<<testcontext-junit4-rules, Spring's support for JUnit rules>> instead.
xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit4-rules[Spring's support for JUnit rules] instead.
The following code listing shows the minimal requirements for configuring a test class to
run with the custom Spring `Runner`:
@@ -140,8 +140,8 @@ extend `AbstractTransactionalJUnit4SpringContextTests`, you can access a `protec
database. You can use such queries to confirm database state both before and after
running database-related application code, and Spring ensures that such queries run in
the scope of the same transaction as the application code. When used in conjunction with
an ORM tool, be sure to avoid <<testcontext-tx-false-positives, false positives>>.
As mentioned in <<integration-testing-support-jdbc>>,
an ORM tool, be sure to avoid xref:testing/testcontext-framework/tx.adoc#testcontext-tx-false-positives[false positives].
As mentioned in xref:testing/support-jdbc.adoc[JDBC Testing Support],
`AbstractTransactionalJUnit4SpringContextTests` also provides convenience methods that
delegate to methods in `JdbcTestUtils` by using the aforementioned `jdbcTemplate`.
Furthermore, `AbstractTransactionalJUnit4SpringContextTests` provides an
@@ -149,8 +149,8 @@ Furthermore, `AbstractTransactionalJUnit4SpringContextTests` provides an
TIP: These classes are a convenience for extension. If you do not want your test classes
to be tied to a Spring-specific class hierarchy, you can configure your own custom test
classes by using `@RunWith(SpringRunner.class)` or <<testcontext-junit4-rules, Spring's
JUnit rules>>.
classes by using `@RunWith(SpringRunner.class)` or xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit4-rules[Spring's JUnit rules]
.
[[testcontext-junit-jupiter-extension]]
== SpringExtension for JUnit Jupiter
@@ -167,14 +167,14 @@ following features above and beyond the feature set that Spring supports for JUn
TestNG:
* Dependency injection for test constructors, test methods, and test lifecycle callback
methods. See <<testcontext-junit-jupiter-di>> for further details.
methods. See xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-di[Dependency Injection with `SpringExtension`] for further details.
* Powerful support for link:https://junit.org/junit5/docs/current/user-guide/#extensions-conditions[conditional
test execution] based on SpEL expressions, environment variables, system properties,
and so on. See the documentation for `@EnabledIf` and `@DisabledIf` in
<<integration-testing-annotations-junit-jupiter>> for further details and examples.
xref:testing/annotations/integration-junit-jupiter.adoc[Spring JUnit Jupiter Testing Annotations] for further details and examples.
* Custom composed annotations that combine annotations from Spring and JUnit Jupiter. See
the `@TransactionalDevTestConfig` and `@TransactionalIntegrationTest` examples in
<<integration-testing-annotations-meta>> for further details.
xref:testing/annotations/integration-meta.adoc[Meta-Annotation Support for Testing] for further details.
The following code listing shows how to configure a test class to use the
`SpringExtension` in conjunction with `@ContextConfiguration`:
@@ -282,7 +282,7 @@ Similarly, the following example uses `@SpringJUnitWebConfig` to create a
----
See the documentation for `@SpringJUnitConfig` and `@SpringJUnitWebConfig` in
<<integration-testing-annotations-junit-jupiter>> for further details.
xref:testing/annotations/integration-junit-jupiter.adoc[Spring JUnit Jupiter Testing Annotations] for further details.
[[testcontext-junit-jupiter-di]]
=== Dependency Injection with `SpringExtension`
@@ -314,7 +314,7 @@ autowirable if one of the following conditions is met (in order of precedence).
attribute set to `ALL`.
* The default _test constructor autowire mode_ has been changed to `ALL`.
See <<integration-testing-annotations-testconstructor>> for details on the use of
See xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-testconstructor[`@TestConstructor`] for details on the use of
`@TestConstructor` and how to change the global _test constructor autowire mode_.
WARNING: If the constructor for a test class is considered to be _autowirable_, Spring
@@ -375,7 +375,7 @@ In the following example, Spring injects the `OrderService` bean from the
Note that this feature lets test dependencies be `final` and therefore immutable.
If the `spring.test.constructor.autowire.mode` property is to `all` (see
<<integration-testing-annotations-testconstructor>>), we can omit the declaration of
xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-testconstructor[`@TestConstructor`]), we can omit the declaration of
`@Autowired` on the constructor in the previous example, resulting in the following.
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
@@ -502,16 +502,16 @@ recursively.
In order to allow development teams to change the default to `OVERRIDE` – for example,
for compatibility with Spring Framework 5.0 through 5.2 – the default mode can be changed
globally via a JVM system property or a `spring.properties` file in the root of the
classpath. See the <<integration-testing-annotations-nestedtestconfiguration, "Changing
the default enclosing configuration inheritance mode">> note for details.
classpath. See the xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-nestedtestconfiguration["Changing the default enclosing configuration inheritance mode"]
note for details.
Although the following "Hello World" example is very simplistic, it shows how to declare
common configuration on a top-level class that is inherited by its `@Nested` test
classes. In this particular example, only the `TestConfig` configuration class is
inherited. Each nested test class provides its own set of active profiles, resulting in a
distinct `ApplicationContext` for each nested test class (see
<<testcontext-ctx-management-caching>> for details). Consult the list of
<<integration-testing-annotations-nestedtestconfiguration, supported annotations>> to see
xref:testing/testcontext-framework/ctx-management/caching.adoc[Context Caching] for details). Consult the list of
xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-nestedtestconfiguration[supported annotations] to see
which annotations can be inherited in `@Nested` test classes.
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
@@ -594,8 +594,8 @@ extend `AbstractTransactionalTestNGSpringContextTests`, you can access a `protec
database. You can use such queries to confirm database state both before and after
running database-related application code, and Spring ensures that such queries run in
the scope of the same transaction as the application code. When used in conjunction with
an ORM tool, be sure to avoid <<testcontext-tx-false-positives, false positives>>.
As mentioned in <<integration-testing-support-jdbc>>,
an ORM tool, be sure to avoid xref:testing/testcontext-framework/tx.adoc#testcontext-tx-false-positives[false positives].
As mentioned in xref:testing/support-jdbc.adoc[JDBC Testing Support],
`AbstractTransactionalTestNGSpringContextTests` also provides convenience methods that
delegate to methods in `JdbcTestUtils` by using the aforementioned `jdbcTemplate`.
Furthermore, `AbstractTransactionalTestNGSpringContextTests` provides an

14
framework-docs/modules/ROOT/pages/testing/testcontext-framework/tel-config.adoc
View File

@@ -9,7 +9,7 @@ by default, exactly in the following order:
* `DirtiesContextBeforeModesTestExecutionListener`: Handles the `@DirtiesContext`
annotation for "`before`" modes.
* `ApplicationEventsTestExecutionListener`: Provides support for
<<testcontext-application-events, `ApplicationEvents`>>.
xref:testing/testcontext-framework/application-events.adoc[`ApplicationEvents`].
* `DependencyInjectionTestExecutionListener`: Provides dependency injection for the test
instance.
* `DirtiesContextTestExecutionListener`: Handles the `@DirtiesContext` annotation for
@@ -19,14 +19,14 @@ by default, exactly in the following order:
* `SqlScriptsTestExecutionListener`: Runs SQL scripts configured by using the `@Sql`
annotation.
* `EventPublishingTestExecutionListener`: Publishes test execution events to the test's
`ApplicationContext` (see <<testcontext-test-execution-events>>).
`ApplicationContext` (see xref:testing/testcontext-framework/test-execution-events.adoc[Test Execution Events]).
[[testcontext-tel-config-registering-tels]]
== Registering `TestExecutionListener` Implementations
You can register `TestExecutionListener` implementations explicitly for a test class, its
subclasses, and its nested classes by using the `@TestExecutionListeners` annotation. See
<<integration-testing-annotations, annotation support>> and the javadoc for
xref:testing/annotations.adoc[annotation support] and the javadoc for
{api-spring-framework}/test/context/TestExecutionListeners.html[`@TestExecutionListeners`]
for details and examples.
@@ -84,7 +84,7 @@ file.
== Ordering `TestExecutionListener` Implementations
When the TestContext framework discovers default `TestExecutionListener` implementations
through the <<testcontext-tel-config-automatic-discovery, aforementioned>>
through the xref:testing/testcontext-framework/tel-config.adoc#testcontext-tel-config-automatic-discovery[aforementioned]
`SpringFactoriesLoader` mechanism, the instantiated listeners are sorted by using
Spring's `AnnotationAwareOrderComparator`, which honors Spring's `Ordered` interface and
`@Order` annotation for ordering. `AbstractTestExecutionListener` and all default
@@ -145,15 +145,15 @@ change from release to release -- for example, `SqlScriptsTestExecutionListener`
introduced in Spring Framework 4.1, and `DirtiesContextBeforeModesTestExecutionListener`
was introduced in Spring Framework 4.2. Furthermore, third-party frameworks like Spring
Boot and Spring Security register their own default `TestExecutionListener`
implementations by using the aforementioned <<testcontext-tel-config-automatic-discovery,
automatic discovery mechanism>>.
implementations by using the aforementioned xref:testing/testcontext-framework/tel-config.adoc#testcontext-tel-config-automatic-discovery[automatic discovery mechanism]
.
To avoid having to be aware of and re-declare all default listeners, you can set the
`mergeMode` attribute of `@TestExecutionListeners` to `MergeMode.MERGE_WITH_DEFAULTS`.
`MERGE_WITH_DEFAULTS` indicates that locally declared listeners should be merged with the
default listeners. The merging algorithm ensures that duplicates are removed from the
list and that the resulting set of merged listeners is sorted according to the semantics
of `AnnotationAwareOrderComparator`, as described in <<testcontext-tel-config-ordering>>.
of `AnnotationAwareOrderComparator`, as described in xref:testing/testcontext-framework/tel-config.adoc#testcontext-tel-config-ordering[Ordering `TestExecutionListener` Implementations].
If a listener implements `Ordered` or is annotated with `@Order`, it can influence the
position in which it is merged with the defaults. Otherwise, locally declared listeners
are appended to the list of default listeners when merged.

6
framework-docs/modules/ROOT/pages/testing/testcontext-framework/test-execution-events.adoc
View File

@@ -52,7 +52,7 @@ In order to listen to test execution events, a Spring bean may choose to impleme
`org.springframework.context.ApplicationListener` interface. Alternatively, listener
methods can be annotated with `@EventListener` and configured to listen to one of the
particular event types listed above (see
<<core.adoc#context-functionality-events-annotation, Annotation-based Event Listeners>>).
xref:core/beans/context-introduction.adoc#context-functionality-events-annotation[Annotation-based Event Listeners]).
Due to the popularity of this approach, Spring provides the following dedicated
`@EventListener` annotations to simplify registration of test execution event listeners.
These annotations reside in the `org.springframework.test.context.event.annotation`
@@ -81,8 +81,8 @@ asynchronous exception handling, consult the class-level javadoc for `@EventList
== Asynchronous Listeners
If you want a particular test execution event listener to process events asynchronously,
you can use Spring's <<integration.adoc#scheduling-annotation-support-async,regular
`@Async` support>>. For further details, consult the class-level javadoc for
you can use Spring's xref:integration/scheduling.adoc#scheduling-annotation-support-async[regular `@Async` support]
. For further details, consult the class-level javadoc for
`@EventListener`.

20
framework-docs/modules/ROOT/pages/testing/testcontext-framework/tx.adoc
View File

@@ -21,7 +21,7 @@ application code that is invoked by tests). Spring-managed and application-manag
transactions typically participate in test-managed transactions. However, you should use
caution if Spring-managed or application-managed transactions are configured with any
propagation type other than `REQUIRED` or `SUPPORTS` (see the discussion on
<<data-access.adoc#tx-propagation, transaction propagation>> for details).
xref:data-access/transaction/declarative/tx-propagation.adoc[transaction propagation] for details).
.Preemptive timeouts and test-managed transactions
[WARNING]
@@ -94,9 +94,9 @@ your test class and then use that with a `TransactionTemplate` for programmatic
transaction management.
====
Note that <<testcontext-support-classes-junit4,
`AbstractTransactionalJUnit4SpringContextTests`>> and
<<testcontext-support-classes-testng, `AbstractTransactionalTestNGSpringContextTests`>>
Note that xref:testing/testcontext-framework/support-classes.adoc#testcontext-support-classes-junit4[`AbstractTransactionalJUnit4SpringContextTests`]
and
xref:testing/testcontext-framework/support-classes.adoc#testcontext-support-classes-testng[`AbstractTransactionalTestNGSpringContextTests`]
are preconfigured for transactional support at the class level.
The following example demonstrates a common scenario for writing an integration test for
@@ -188,7 +188,7 @@ a Hibernate-based `UserRepository`:
}
----
As explained in <<testcontext-tx-rollback-and-commit-behavior>>, there is no need to
As explained in xref:testing/testcontext-framework/tx.adoc#testcontext-tx-rollback-and-commit-behavior[Transaction Rollback and Commit Behavior], there is no need to
clean up the database after the `createUser()` method runs, since any changes made to the
database are automatically rolled back by the `TransactionalTestExecutionListener`.
@@ -198,7 +198,7 @@ database are automatically rolled back by the `TransactionalTestExecutionListene
By default, test transactions will be automatically rolled back after completion of the
test; however, transactional commit and rollback behavior can be configured declaratively
via the `@Commit` and `@Rollback` annotations. See the corresponding entries in the
<<integration-testing-annotations, annotation support>> section for further details.
xref:testing/annotations.adoc[annotation support] section for further details.
[[testcontext-tx-programmatic-tx-mgt]]
== Programmatic Transaction Management
@@ -312,9 +312,9 @@ algorithm used to look up a transaction manager in the test's `ApplicationContex
The following JUnit Jupiter based example displays a fictitious integration testing
scenario that highlights all transaction-related annotations. The example is not intended
to demonstrate best practices but rather to demonstrate how these annotations can be
used. See the <<integration-testing-annotations, annotation support>> section for further
information and configuration examples. <<testcontext-executing-sql-declaratively-tx,
Transaction management for `@Sql`>> contains an additional example that uses `@Sql` for
used. See the xref:testing/annotations.adoc[annotation support] section for further
information and configuration examples. xref:testing/testcontext-framework/executing-sql.adoc#testcontext-executing-sql-declaratively-tx[Transaction management for `@Sql`]
contains an additional example that uses `@Sql` for
declarative SQL script execution with default transaction rollback semantics. The
following example shows the relevant annotations:
@@ -521,7 +521,7 @@ The following example shows matching methods for JPA:
.Testing ORM entity lifecycle callbacks
[NOTE]
=====
Similar to the note about avoiding <<testcontext-tx-false-positives, false positives>>
Similar to the note about avoiding xref:testing/testcontext-framework/tx.adoc#testcontext-tx-false-positives[false positives]
when testing ORM code, if your application makes use of entity lifecycle callbacks (also
known as entity listeners), make sure to flush the underlying unit of work within test
methods that run that code. Failing to _flush_ or _clear_ the underlying unit of work can

6
framework-docs/modules/ROOT/pages/testing/testcontext-framework/web-scoped-beans.adoc
View File

@@ -1,8 +1,8 @@
[[testcontext-web-scoped-beans]]
= Testing Request- and Session-scoped Beans
Spring has supported <<core#beans-factory-scopes-other, Request- and session-scoped
beans>> since the early years, and you can test your request-scoped and session-scoped
Spring has supported xref:core/beans/factory-scopes.adoc#beans-factory-scopes-other[Request- and session-scoped beans]
since the early years, and you can test your request-scoped and session-scoped
beans by following these steps:
* Ensure that a `WebApplicationContext` is loaded for your test by annotating your test
@@ -15,7 +15,7 @@ beans by following these steps:
The next code snippet shows the XML configuration for a login use case. Note that the
`userService` bean has a dependency on a request-scoped `loginAction` bean. Also, the
`LoginAction` is instantiated by using <<core.adoc#expressions, SpEL expressions>> that
`LoginAction` is instantiated by using xref:core/expressions.adoc[SpEL expressions] that
retrieve the username and password from the current HTTP request. In our test, we want to
configure these request parameters through the mock managed by the TestContext framework.
The following listing shows the configuration for this use case:

26
framework-docs/modules/ROOT/pages/testing/unit.adoc
View File

@@ -4,7 +4,7 @@
Dependency injection should make your code less dependent on the container than it would
be with traditional J2EE / Java EE development. The POJOs that make up your application
should be testable in JUnit or TestNG tests, with objects instantiated by using the `new`
operator, without Spring or any other container. You can use <<mock-objects, mock objects>>
operator, without Spring or any other container. You can use xref:testing/unit.adoc#mock-objects[mock objects]
(in conjunction with other valuable testing techniques) to test your code in isolation.
If you follow the architecture recommendations for Spring, the resulting clean layering
and componentization of your codebase facilitate easier unit testing. For example,
@@ -25,10 +25,10 @@ are described in this chapter.
Spring includes a number of packages dedicated to mocking:
* <<mock-objects-env>>
* <<mock-objects-jndi>>
* <<mock-objects-servlet>>
* <<mock-objects-web-reactive>>
* xref:testing/unit.adoc#mock-objects-env[Environment]
* xref:testing/unit.adoc#mock-objects-jndi[JNDI]
* xref:testing/unit.adoc#mock-objects-servlet[Servlet API]
* xref:testing/unit.adoc#mock-objects-web-reactive[Spring Web Reactive]
[[mock-objects-env]]
@@ -36,8 +36,8 @@ Spring includes a number of packages dedicated to mocking:
The `org.springframework.mock.env` package contains mock implementations of the
`Environment` and `PropertySource` abstractions (see
<<core.adoc#beans-definition-profiles, Bean Definition Profiles>>
and <<core.adoc#beans-property-source-abstraction, `PropertySource` Abstraction>>).
xref:core/beans/environment.adoc#beans-definition-profiles[Bean Definition Profiles]
and xref:core/beans/environment.adoc#beans-property-source-abstraction[`PropertySource` Abstraction]).
`MockEnvironment` and `MockPropertySource` are useful for developing
out-of-container tests for code that depends on environment-specific properties.
@@ -69,7 +69,7 @@ TIP: Since Spring Framework 6.0, the mock objects in `org.springframework.mock.w
based on the Servlet 6.0 API.
The Spring MVC Test framework builds on the mock Servlet API objects to provide an
integration testing framework for Spring MVC. See <<spring-mvc-test-framework>>.
integration testing framework for Spring MVC. See xref:testing/spring-mvc-test-framework.adoc[MockMvc].
[[mock-objects-web-reactive]]
@@ -90,7 +90,7 @@ write completion handle (that is, `Mono<Void>`), it by default uses a `Flux` wit
`cache().then()`, which buffers the data and makes it available for assertions in tests.
Applications can set a custom write function (for example, to test an infinite stream).
The <<webtestclient>> builds on the mock request and response to provide support for
The xref:testing/webtestclient.adoc[WebTestClient] builds on the mock request and response to provide support for
testing WebFlux applications without an HTTP server. The client can also be used for
end-to-end tests with a running server.
@@ -102,8 +102,8 @@ end-to-end tests with a running server.
Spring includes a number of classes that can help with unit testing. They fall into two
categories:
* <<unit-testing-utilities>>
* <<unit-testing-spring-mvc>>
* xref:testing/unit.adoc#unit-testing-utilities[General Testing Utilities]
* xref:testing/unit.adoc#unit-testing-spring-mvc[Spring MVC Testing Utilities]
[[unit-testing-utilities]]
@@ -162,7 +162,7 @@ that deal with Spring MVC `ModelAndView` objects.
.Unit testing Spring MVC Controllers
TIP: To unit test your Spring MVC `Controller` classes as POJOs, use `ModelAndViewAssert`
combined with `MockHttpServletRequest`, `MockHttpSession`, and so on from Spring's
<<mock-objects-servlet, Servlet API mocks>>. For thorough integration testing of your
xref:testing/unit.adoc#mock-objects-servlet[Servlet API mocks]. For thorough integration testing of your
Spring MVC and REST `Controller` classes in conjunction with your `WebApplicationContext`
configuration for Spring MVC, use the
<<spring-mvc-test-framework, Spring MVC Test Framework>> instead.
xref:testing/spring-mvc-test-framework.adoc[Spring MVC Test Framework] instead.

24
framework-docs/modules/ROOT/pages/testing/webtestclient.adoc
View File

@@ -2,12 +2,12 @@
= WebTestClient
`WebTestClient` is an HTTP client designed for testing server applications. It wraps
Spring's <<web-reactive.adoc#webflux-client, WebClient>> and uses it to perform requests
Spring's xref:web/webflux-webclient.adoc[WebClient] and uses it to perform requests
but exposes a testing facade for verifying responses. `WebTestClient` can be used to
perform end-to-end HTTP tests. It can also be used to test Spring MVC and Spring WebFlux
applications without a running server via mock server request and response objects.
TIP: Kotlin users: See <<languages.adoc#kotlin-webtestclient-issue, this section>>
TIP: Kotlin users: See xref:languages/kotlin/spring-projects-in.adoc#kotlin-webtestclient-issue[this section]
related to use of the `WebTestClient`.
@@ -28,8 +28,8 @@ This setup allows you to test specific controller(s) via mock request and respon
without a running server.
For WebFlux applications, use the following which loads infrastructure equivalent to the
<<web-reactive.adoc#webflux-config, WebFlux Java config>>, registers the given
controller(s), and creates a <<web-reactive.adoc#webflux-web-handler-api, WebHandler chain>>
xref:web/webflux/dispatcher-handler.adoc#webflux-framework-config[WebFlux Java config], registers the given
controller(s), and creates a xref:web/webflux/reactive-spring.adoc#webflux-web-handler-api[WebHandler chain]
to handle requests:
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
@@ -46,9 +46,9 @@ to handle requests:
For Spring MVC, use the following which delegates to the
{api-spring-framework}/test/web/servlet/setup/StandaloneMockMvcBuilder.html[StandaloneMockMvcBuilder]
to load infrastructure equivalent to the <<web.adoc#mvc-config, WebMvc Java config>>,
to load infrastructure equivalent to the xref:web/webmvc/mvc-config.adoc[WebMvc Java config],
registers the given controller(s), and creates an instance of
<<testing.adoc#spring-mvc-test-framework, MockMvc>> to handle requests:
xref:testing/spring-mvc-test-framework.adoc[MockMvc] to handle requests:
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
@@ -73,7 +73,7 @@ and response objects, without a running server.
For WebFlux, use the following where the Spring `ApplicationContext` is passed to
{api-spring-framework}/web/server/adapter/WebHttpHandlerBuilder.html#applicationContext-org.springframework.context.ApplicationContext-[WebHttpHandlerBuilder]
to create the <<web-reactive.adoc#webflux-web-handler-api, WebHandler chain>> to handle
to create the xref:web/webflux/reactive-spring.adoc#webflux-web-handler-api[WebHandler chain] to handle
requests:
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
@@ -114,7 +114,7 @@ requests:
For Spring MVC, use the following where the Spring `ApplicationContext` is passed to
{api-spring-framework}/test/web/servlet/setup/MockMvcBuilders.html#webAppContextSetup-org.springframework.web.context.WebApplicationContext-[MockMvcBuilders.webAppContextSetup]
to create a <<testing.adoc#spring-mvc-test-framework, MockMvc>> instance to handle
to create a xref:testing/spring-mvc-test-framework.adoc[MockMvc] instance to handle
requests:
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
@@ -194,7 +194,7 @@ create a server setup to handle requests:
----
For Spring MVC there are currently no options to test
<<web.adoc#webmvc-fn, WebMvc functional endpoints>>.
xref:web/webmvc-functional.adoc[WebMvc functional endpoints].
@@ -248,9 +248,9 @@ follows:
[[webtestclient-tests]]
== Writing Tests
`WebTestClient` provides an API identical to <<web-reactive.adoc#webflux-client, WebClient>>
`WebTestClient` provides an API identical to xref:web/webflux-webclient.adoc[WebClient]
up to the point of performing a request by using `exchange()`. See the
<<web-reactive.adoc#webflux-client-body, WebClient>> documentation for examples on how to
xref:web/webflux-webclient/client-body.adoc[WebClient] documentation for examples on how to
prepare a request with any content including form data, multipart data, and more.
After the call to `exchange()`, `WebTestClient` diverges from the `WebClient` and
@@ -298,7 +298,7 @@ You can then choose to decode the response body through one of the following:
* `expectBody(Class<T>)`: Decode to single object.
* `expectBodyList(Class<T>)`: Decode and collect objects to `List<T>`.
* `expectBody()`: Decode to `byte[]` for <<webtestclient-json>> or an empty body.
* `expectBody()`: Decode to `byte[]` for xref:testing/webtestclient.adoc#webtestclient-json[JSON Content] or an empty body.
And perform assertions on the resulting higher level Object(s):