Migrate to Asciidoctor Tabs

This commit is contained in:
Rob Winch
2023-04-20 16:21:36 -05:00
committed by rstoyanchev
parent 71154fd16b
commit 39146f9066
243 changed files with 7124 additions and 1779 deletions

View File

@@ -25,14 +25,18 @@ classes may be declared with the `value` attribute in `@SpringJUnitConfig`.
The following example shows how to use the `@SpringJUnitConfig` annotation to specify a
configuration class:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@SpringJUnitConfig(TestConfig.class) // <1>
class ConfigurationClassJUnitJupiterSpringTests {
// class body...
}
----
======
<1> Specify the configuration class.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -49,14 +53,18 @@ configuration class:
The following example shows how to use the `@SpringJUnitConfig` annotation to specify the
location of a configuration file:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@SpringJUnitConfig(locations = "/test-config.xml") // <1>
class XmlJUnitJupiterSpringTests {
// class body...
}
----
======
<1> Specify the location of a configuration file.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -90,14 +98,18 @@ attribute from `@WebAppConfiguration` only by using the `resourcePath` attribute
The following example shows how to use the `@SpringJUnitWebConfig` annotation to specify
a configuration class:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@SpringJUnitWebConfig(TestConfig.class) // <1>
class ConfigurationClassJUnitJupiterSpringWebTests {
// class body...
}
----
======
<1> Specify the configuration class.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -114,14 +126,18 @@ a configuration class:
The following example shows how to use the `@SpringJUnitWebConfig` annotation to specify the
location of a configuration file:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@SpringJUnitWebConfig(locations = "/test-config.xml") // <1>
class XmlJUnitJupiterSpringWebTests {
// class body...
}
----
======
<1> Specify the location of a configuration file.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -248,8 +264,11 @@ equivalent to `@Disabled` and `@EnabledIf("true")` is logically meaningless.
You can use `@EnabledIf` as a meta-annotation to create custom composed annotations. For
example, you can create a custom `@EnabledOnMac` annotation as follows:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@@ -259,8 +278,10 @@ example, you can create a custom `@EnabledOnMac` annotation as follows:
)
public @interface EnabledOnMac {}
----
Kotlin::
+
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
.Kotlin
----
@Target(AnnotationTarget.TYPE, AnnotationTarget.FUNCTION)
@Retention(AnnotationRetention.RUNTIME)
@@ -270,6 +291,7 @@ example, you can create a custom `@EnabledOnMac` annotation as follows:
)
annotation class EnabledOnMac {}
----
======
[NOTE]
====
@@ -308,8 +330,11 @@ equivalent to `@Disabled` and `@DisabledIf("false")` is logically meaningless.
You can use `@DisabledIf` as a meta-annotation to create custom composed annotations. For
example, you can create a custom `@DisabledOnMac` annotation as follows:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@@ -320,8 +345,9 @@ example, you can create a custom `@DisabledOnMac` annotation as follows:
public @interface DisabledOnMac {}
----
Kotlin::
+
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
.Kotlin
----
@Target(AnnotationTarget.TYPE, AnnotationTarget.FUNCTION)
@Retention(AnnotationRetention.RUNTIME)
@@ -331,6 +357,7 @@ example, you can create a custom `@DisabledOnMac` annotation as follows:
)
annotation class DisabledOnMac {}
----
======
[NOTE]
====

View File

@@ -27,8 +27,11 @@ means the test is implicitly enabled. This is analogous to the semantics of JUni
The following example shows a test that has an `@IfProfileValue` annotation:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@IfProfileValue(name="java.vendor", value="Oracle Corporation") // <1>
@Test
@@ -36,6 +39,7 @@ The following example shows a test that has an `@IfProfileValue` annotation:
// some logic that should run only on Java VMs from Oracle Corporation
}
----
======
<1> Run this test only when the Java vendor is "Oracle Corporation".
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -54,8 +58,11 @@ Alternatively, you can configure `@IfProfileValue` with a list of `values` (with
semantics) to achieve TestNG-like support for test groups in a JUnit 4 environment.
Consider the following example:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@IfProfileValue(name="test-groups", values={"unit-tests", "integration-tests"}) // <1>
@Test
@@ -63,6 +70,7 @@ Consider the following example:
// some logic that should run only for unit and integration test groups
}
----
======
<1> Run this test for unit tests and integration tests.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -86,14 +94,18 @@ of `ProfileValueSource` to use when retrieving profile values configured through
test, `SystemProfileValueSource` is used by default. The following example shows how to
use `@ProfileValueSourceConfiguration`:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@ProfileValueSourceConfiguration(CustomProfileValueSource.class) // <1>
public class CustomProfileValueSourceTests {
// class body...
}
----
======
<1> Use a custom profile value source.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -118,14 +130,18 @@ The time period includes running the test method itself, any repetitions of the
`@Repeat`), as well as any setting up or tearing down of the test fixture. The following
example shows how to use it:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@Timed(millis = 1000) // <1>
public void testProcessWithOneSecondTimeout() {
// some logic that should not take longer than 1 second to run
}
----
======
<1> Set the time period for the test to one second.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -158,8 +174,11 @@ xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit4-rules
preparation of the test instance by `TestExecutionListener` implementations. The
following example shows how to use the `@Repeat` annotation:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@Repeat(10) // <1>
@Test
@@ -167,6 +186,7 @@ following example shows how to use the `@Repeat` annotation:
// ...
}
----
======
<1> Repeat this test ten times.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]

View File

@@ -38,8 +38,11 @@ xref:testing/testcontext-framework.adoc[TestContext framework].
Consider the following example:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@RunWith(SpringRunner.class)
@ContextConfiguration({"/app-config.xml", "/test-data-access-config.xml"})
@@ -54,8 +57,9 @@ Consider the following example:
public class UserRepositoryTests { }
----
Kotlin::
+
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
.Kotlin
----
@RunWith(SpringRunner::class)
@ContextConfiguration("/app-config.xml", "/test-data-access-config.xml")
@@ -69,13 +73,17 @@ Consider the following example:
@Transactional
class UserRepositoryTests { }
----
======
If we discover that we are repeating the preceding configuration across our JUnit 4-based
test suite, we can reduce the duplication by introducing a custom composed annotation
that centralizes the common test configuration for Spring, as follows:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@@ -85,8 +93,9 @@ that centralizes the common test configuration for Spring, as follows:
public @interface TransactionalDevTestConfig { }
----
Kotlin::
+
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
.Kotlin
----
@Target(AnnotationTarget.TYPE)
@Retention(AnnotationRetention.RUNTIME)
@@ -95,12 +104,16 @@ that centralizes the common test configuration for Spring, as follows:
@Transactional
annotation class TransactionalDevTestConfig { }
----
======
Then we can use our custom `@TransactionalDevTestConfig` annotation to simplify the
configuration of individual JUnit 4 based test classes, as follows:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@RunWith(SpringRunner.class)
@TransactionalDevTestConfig
@@ -111,8 +124,9 @@ configuration of individual JUnit 4 based test classes, as follows:
public class UserRepositoryTests { }
----
Kotlin::
+
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
.Kotlin
----
@RunWith(SpringRunner::class)
@TransactionalDevTestConfig
@@ -122,13 +136,17 @@ configuration of individual JUnit 4 based test classes, as follows:
@TransactionalDevTestConfig
class UserRepositoryTests
----
======
If we write tests that use JUnit Jupiter, we can reduce code duplication even further,
since annotations in JUnit 5 can also be used as meta-annotations. Consider the following
example:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@ExtendWith(SpringExtension.class)
@ContextConfiguration({"/app-config.xml", "/test-data-access-config.xml"})
@@ -142,8 +160,10 @@ example:
@Transactional
class UserRepositoryTests { }
----
Kotlin::
+
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
.Kotlin
----
@ExtendWith(SpringExtension::class)
@ContextConfiguration("/app-config.xml", "/test-data-access-config.xml")
@@ -157,14 +177,18 @@ example:
@Transactional
class UserRepositoryTests { }
----
======
If we discover that we are repeating the preceding configuration across our JUnit
Jupiter-based test suite, we can reduce the duplication by introducing a custom composed
annotation that centralizes the common test configuration for Spring and JUnit Jupiter,
as follows:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@@ -174,8 +198,10 @@ as follows:
@Transactional
public @interface TransactionalDevTestConfig { }
----
Kotlin::
+
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
.Kotlin
----
@Target(AnnotationTarget.TYPE)
@Retention(AnnotationRetention.RUNTIME)
@@ -185,12 +211,16 @@ as follows:
@Transactional
annotation class TransactionalDevTestConfig { }
----
======
Then we can use our custom `@TransactionalDevTestConfig` annotation to simplify the
configuration of individual JUnit Jupiter based test classes, as follows:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@TransactionalDevTestConfig
class OrderRepositoryTests { }
@@ -198,8 +228,10 @@ configuration of individual JUnit Jupiter based test classes, as follows:
@TransactionalDevTestConfig
class UserRepositoryTests { }
----
Kotlin::
+
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
.Kotlin
----
@TransactionalDevTestConfig
class OrderRepositoryTests { }
@@ -207,6 +239,7 @@ configuration of individual JUnit Jupiter based test classes, as follows:
@TransactionalDevTestConfig
class UserRepositoryTests { }
----
======
Since JUnit Jupiter supports the use of `@Test`, `@RepeatedTest`, `ParameterizedTest`,
and others as meta-annotations, you can also create custom composed annotations at the
@@ -215,8 +248,11 @@ the `@Test` and `@Tag` annotations from JUnit Jupiter with the `@Transactional`
annotation from Spring, we could create an `@TransactionalIntegrationTest` annotation, as
follows:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@@ -225,8 +261,10 @@ follows:
@Test // org.junit.jupiter.api.Test
public @interface TransactionalIntegrationTest { }
----
Kotlin::
+
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
.Kotlin
----
@Target(AnnotationTarget.TYPE)
@Retention(AnnotationRetention.RUNTIME)
@@ -235,12 +273,16 @@ follows:
@Test // org.junit.jupiter.api.Test
annotation class TransactionalIntegrationTest { }
----
======
Then we can use our custom `@TransactionalIntegrationTest` annotation to simplify the
configuration of individual JUnit Jupiter based test methods, as follows:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@TransactionalIntegrationTest
void saveOrder() { }
@@ -249,8 +291,9 @@ configuration of individual JUnit Jupiter based test methods, as follows:
void deleteOrder() { }
----
Kotlin::
+
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
.Kotlin
----
@TransactionalIntegrationTest
fun saveOrder() { }
@@ -258,6 +301,7 @@ configuration of individual JUnit Jupiter based test methods, as follows:
@TransactionalIntegrationTest
fun deleteOrder() { }
----
======
For further details, see the
https://github.com/spring-projects/spring-framework/wiki/Spring-Annotation-Programming-Model[Spring Annotation Programming Model]

View File

@@ -7,8 +7,11 @@ integration test.
The following example indicates that the `dev` profile should be active:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@ContextConfiguration
@ActiveProfiles("dev") // <1>
@@ -16,6 +19,7 @@ The following example indicates that the `dev` profile should be active:
// class body...
}
----
======
<1> Indicate that the `dev` profile should be active.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -33,8 +37,11 @@ The following example indicates that the `dev` profile should be active:
The following example indicates that both the `dev` and the `integration` profiles should
be active:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@ContextConfiguration
@ActiveProfiles({"dev", "integration"}) // <1>
@@ -42,6 +49,7 @@ be active:
// class body...
}
----
======
<1> Indicate that the `dev` and `integration` profiles should be active.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]

View File

@@ -7,14 +7,18 @@ transaction by using Spring's `@Transactional` annotation. `@AfterTransaction` m
are not required to be `public` and may be declared on Java 8-based interface default
methods.
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@AfterTransaction // <1>
void afterTransaction() {
// logic to be run after a transaction has ended
}
----
======
<1> Run this method after a transaction.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]

View File

@@ -9,14 +9,18 @@ methods.
The following example shows how to use the `@BeforeTransaction` annotation:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@BeforeTransaction // <1>
void beforeTransaction() {
// logic to be run before a transaction is started
}
----
======
<1> Run this method before a transaction.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]

View File

@@ -9,8 +9,11 @@ annotation.
The following example shows how to use the `@Commit` annotation:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@Commit // <1>
@Test
@@ -18,6 +21,7 @@ The following example shows how to use the `@Commit` annotation:
// ...
}
----
======
<1> Commit the result of the test to the database.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]

View File

@@ -15,14 +15,18 @@ xref:testing/testcontext-framework/ctx-management/javaconfig.adoc#testcontext-ct
The following example shows a `@ContextConfiguration` annotation that refers to an XML
file:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@ContextConfiguration("/test-config.xml") // <1>
class XmlApplicationContextTests {
// class body...
}
----
======
<1> Referring to an XML file.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -38,14 +42,18 @@ file:
The following example shows a `@ContextConfiguration` annotation that refers to a class:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@ContextConfiguration(classes = TestConfig.class) // <1>
class ConfigClassApplicationContextTests {
// class body...
}
----
======
<1> Referring to a class.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -63,14 +71,18 @@ As an alternative or in addition to declaring resource locations or component cl
you can use `@ContextConfiguration` to declare `ApplicationContextInitializer` classes.
The following example shows such a case:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@ContextConfiguration(initializers = CustomContextInitializer.class) // <1>
class ContextInitializerTests {
// class body...
}
----
======
<1> Declaring an initializer class.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -91,14 +103,18 @@ component `classes`.
The following example uses both a location and a loader:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@ContextConfiguration(locations = "/test-context.xml", loader = CustomContextLoader.class) // <1>
class CustomLoaderXmlApplicationContextTests {
// class body...
}
----
======
<1> Configuring both a location and a custom loader.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]

View File

@@ -8,8 +8,11 @@ defines a level in the context hierarchy. The following examples demonstrate the
`@ContextHierarchy` within a single test class (`@ContextHierarchy` can also be used
within a test class hierarchy):
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@ContextHierarchy({
@ContextConfiguration("/parent-config.xml"),
@@ -19,8 +22,10 @@ within a test class hierarchy):
// class body...
}
----
Kotlin::
+
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
.Kotlin
----
@ContextHierarchy(
ContextConfiguration("/parent-config.xml"),
@@ -29,9 +34,13 @@ within a test class hierarchy):
// class body...
}
----
======
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@WebAppConfiguration
@ContextHierarchy({
@@ -42,8 +51,10 @@ within a test class hierarchy):
// class body...
}
----
Kotlin::
+
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
.Kotlin
----
@WebAppConfiguration
@ContextHierarchy(
@@ -53,6 +64,7 @@ within a test class hierarchy):
// class body...
}
----
======
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

View File

@@ -20,14 +20,18 @@ configuration scenarios:
* Before the current test class, when declared on a class with class mode set to
`BEFORE_CLASS`.
+
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@DirtiesContext(classMode = BEFORE_CLASS) // <1>
class FreshContextTests {
// some tests that require a new Spring container
}
----
======
<1> Dirty the context before the current test class.
+
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -43,14 +47,18 @@ configuration scenarios:
* After the current test class, when declared on a class with class mode set to
`AFTER_CLASS` (i.e., the default class mode).
+
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@DirtiesContext // <1>
class ContextDirtyingTests {
// some tests that result in the Spring container being dirtied
}
----
======
<1> Dirty the context after the current test class.
+
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -67,14 +75,18 @@ configuration scenarios:
* Before each test method in the current test class, when declared on a class with class
mode set to `BEFORE_EACH_TEST_METHOD.`
+
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@DirtiesContext(classMode = BEFORE_EACH_TEST_METHOD) // <1>
class FreshContextTests {
// some tests that require a new Spring container
}
----
======
<1> Dirty the context before each test method.
+
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -91,14 +103,18 @@ mode set to `BEFORE_EACH_TEST_METHOD.`
* After each test method in the current test class, when declared on a class with class
mode set to `AFTER_EACH_TEST_METHOD.`
+
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@DirtiesContext(classMode = AFTER_EACH_TEST_METHOD) // <1>
class ContextDirtyingTests {
// some tests that result in the Spring container being dirtied
}
----
======
<1> Dirty the context after each test method.
+
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -115,8 +131,11 @@ mode set to `AFTER_EACH_TEST_METHOD.`
* Before the current test, when declared on a method with the method mode set to
`BEFORE_METHOD`.
+
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@DirtiesContext(methodMode = BEFORE_METHOD) // <1>
@Test
@@ -124,6 +143,7 @@ mode set to `AFTER_EACH_TEST_METHOD.`
// some logic that requires a new Spring container
}
----
======
<1> Dirty the context before the current test method.
+
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -140,8 +160,11 @@ mode set to `AFTER_EACH_TEST_METHOD.`
* After the current test, when declared on a method with the method mode set to
`AFTER_METHOD` (i.e., the default method mode).
+
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@DirtiesContext // <1>
@Test
@@ -149,6 +172,7 @@ mode set to `AFTER_EACH_TEST_METHOD.`
// some logic that results in the Spring container being dirtied
}
----
======
<1> Dirty the context after the current test method.
+
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -173,8 +197,11 @@ context are removed from the context cache and closed. If the exhaustive algorit
overkill for a particular use case, you can specify the simpler current level algorithm,
as the following example shows.
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@ContextHierarchy({
@ContextConfiguration("/parent-config.xml"),
@@ -193,6 +220,7 @@ as the following example shows.
}
}
----
======
<1> Use the current-level algorithm.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]

View File

@@ -10,8 +10,11 @@ https://www.testcontainers.org/[Testcontainers] project.
The following example demonstrates how to register a dynamic property:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@ContextConfiguration
class MyIntegrationTests {
@@ -26,6 +29,7 @@ The following example demonstrates how to register a dynamic property:
// tests ...
}
----
======
<1> Annotate a `static` method with `@DynamicPropertySource`.
<2> Accept a `DynamicPropertyRegistry` as an argument.
<3> Register a dynamic `server.port` property to be retrieved lazily from the server.

View File

@@ -15,8 +15,11 @@ method, potentially overriding class-level `@Rollback` or `@Commit` semantics.
The following example causes a test method's result to not be rolled back (that is, the
result is committed to the database):
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@Rollback(false) // <1>
@Test
@@ -24,6 +27,7 @@ result is committed to the database):
// ...
}
----
======
<1> Do not roll back the result.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]

View File

@@ -5,8 +5,11 @@
against a given database during integration tests. The following example shows how to use
it:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@Test
@Sql({"/test-schema.sql", "/test-user-data.sql"}) // <1>
@@ -14,6 +17,7 @@ it:
// run code that relies on the test schema and test data
}
----
======
<1> Run two scripts for this test.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]

View File

@@ -4,8 +4,11 @@
`@SqlConfig` defines metadata that is used to determine how to parse and run SQL scripts
configured with the `@Sql` annotation. The following example shows how to use it:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@Test
@Sql(
@@ -16,6 +19,7 @@ configured with the `@Sql` annotation. The following example shows how to use it
// run code that relies on the test data
}
----
======
<1> Set the comment prefix and the separator in SQL scripts.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]

View File

@@ -7,8 +7,11 @@ in conjunction with Java 8's support for repeatable annotations, where `@Sql` ca
declared several times on the same class or method, implicitly generating this container
annotation. The following example shows how to declare an SQL group:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@Test
@SqlGroup({ // <1>
@@ -19,6 +22,7 @@ annotation. The following example shows how to declare an SQL group:
// run code that uses the test schema and test data
}
----
======
<1> Declare a group of SQL scripts.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]

View File

@@ -11,8 +11,11 @@ Note that a method-level `@SqlMergeMode` declaration overrides a class-level dec
The following example shows how to use `@SqlMergeMode` at the class level.
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@SpringJUnitConfig(TestConfig.class)
@Sql("/test-schema.sql")
@@ -26,6 +29,7 @@ The following example shows how to use `@SqlMergeMode` at the class level.
}
}
----
======
<1> Set the `@Sql` merge mode to `MERGE` for all test methods in the class.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -47,8 +51,11 @@ The following example shows how to use `@SqlMergeMode` at the class level.
The following example shows how to use `@SqlMergeMode` at the method level.
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@SpringJUnitConfig(TestConfig.class)
@Sql("/test-schema.sql")
@@ -62,6 +69,7 @@ The following example shows how to use `@SqlMergeMode` at the method level.
}
}
----
======
<1> Set the `@Sql` merge mode to `MERGE` for a specific test method.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]

View File

@@ -8,8 +8,11 @@ xref:testing/testcontext-framework/tel-config.adoc[`TestExecutionListener` Confi
The following example shows how to register two `TestExecutionListener` implementations:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@ContextConfiguration
@TestExecutionListeners({CustomTestExecutionListener.class, AnotherTestExecutionListener.class}) // <1>
@@ -17,6 +20,7 @@ The following example shows how to register two `TestExecutionListener` implemen
// class body...
}
----
======
<1> Register two `TestExecutionListener` implementations.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]

View File

@@ -8,8 +8,11 @@ integration test.
The following example demonstrates how to declare a properties file from the classpath:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@ContextConfiguration
@TestPropertySource("/test.properties") // <1>
@@ -17,6 +20,7 @@ The following example demonstrates how to declare a properties file from the cla
// class body...
}
----
======
<1> Get properties from `test.properties` in the root of the classpath.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -33,8 +37,11 @@ The following example demonstrates how to declare a properties file from the cla
The following example demonstrates how to declare inlined properties:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@ContextConfiguration
@TestPropertySource(properties = { "timezone = GMT", "port: 4242" }) // <1>
@@ -42,6 +49,7 @@ The following example demonstrates how to declare inlined properties:
// class body...
}
----
======
<1> Declare `timezone` and `port` properties.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]

View File

@@ -13,8 +13,11 @@ resource base path). The resource base path is used behind the scenes to create
The following example shows how to use the `@WebAppConfiguration` annotation:
--
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@ContextConfiguration
@WebAppConfiguration // <1>
@@ -22,6 +25,7 @@ The following example shows how to use the `@WebAppConfiguration` annotation:
// class body...
}
----
======
<1> The `@WebAppConfiguration` annotation.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -43,8 +47,11 @@ supported. If no resource prefix is supplied, the path is assumed to be a file s
resource. The following example shows how to specify a classpath resource:
--
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
.Java
----
@ContextConfiguration
@WebAppConfiguration("classpath:test-web-resources") // <1>
@@ -52,6 +59,7 @@ resource. The following example shows how to specify a classpath resource:
// class body...
}
----
======
<1> Specifying a classpath resource.
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]