Migrate to Asciidoctor Tabs
This commit is contained in:
@@ -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]
|
||||
====
|
||||
|
||||
@@ -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"]
|
||||
|
||||
@@ -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]
|
||||
|
||||
@@ -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"]
|
||||
|
||||
@@ -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"]
|
||||
|
||||
@@ -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"]
|
||||
|
||||
@@ -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"]
|
||||
|
||||
@@ -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"]
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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"]
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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"]
|
||||
|
||||
@@ -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"]
|
||||
|
||||
@@ -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"]
|
||||
|
||||
@@ -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"]
|
||||
|
||||
@@ -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"]
|
||||
|
||||
@@ -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"]
|
||||
|
||||
@@ -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"]
|
||||
|
||||
@@ -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"]
|
||||
|
||||
Reference in New Issue
Block a user