Fix cross references
This commit is contained in:
Rob Winch
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
|
||||
@@ -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].
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user