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

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: