|
|
|
|
@@ -1155,9 +1155,9 @@ result is committed to the database):
|
|
|
|
|
|
|
|
|
|
`@BeforeTransaction` indicates that the annotated `void` method should be run before a
|
|
|
|
|
transaction is started, for test methods that have been configured to run within a
|
|
|
|
|
transaction by using Spring's `@Transactional` annotation. As of Spring Framework 4.3,
|
|
|
|
|
`@BeforeTransaction` methods are not required to be `public` and may be declared on Java
|
|
|
|
|
8-based interface default methods.
|
|
|
|
|
transaction by using Spring's `@Transactional` annotation. `@BeforeTransaction` methods
|
|
|
|
|
are not required to be `public` and may be declared on Java 8-based interface default
|
|
|
|
|
methods.
|
|
|
|
|
|
|
|
|
|
The following example shows how to use the `@BeforeTransaction` annotation:
|
|
|
|
|
|
|
|
|
|
@@ -1187,9 +1187,9 @@ The following example shows how to use the `@BeforeTransaction` annotation:
|
|
|
|
|
|
|
|
|
|
`@AfterTransaction` indicates that the annotated `void` method should be run after a
|
|
|
|
|
transaction is ended, for test methods that have been configured to run within a
|
|
|
|
|
transaction by using Spring's `@Transactional` annotation. As of Spring Framework 4.3,
|
|
|
|
|
`@AfterTransaction` methods are not required to be `public` and may be declared on Java
|
|
|
|
|
8-based interface default methods.
|
|
|
|
|
transaction by using Spring's `@Transactional` annotation. `@AfterTransaction` methods
|
|
|
|
|
are not required to be `public` and may be declared on Java 8-based interface default
|
|
|
|
|
methods.
|
|
|
|
|
|
|
|
|
|
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
|
|
|
|
|
.Java
|
|
|
|
|
@@ -2220,11 +2220,11 @@ integration test managed by the Spring TestContext Framework. You should impleme
|
|
|
|
|
active bean definition profiles, test property sources, context hierarchies, and
|
|
|
|
|
`WebApplicationContext` support.
|
|
|
|
|
|
|
|
|
|
`SmartContextLoader` is an extension of the `ContextLoader` interface introduced in
|
|
|
|
|
Spring 3.1, superseding the original minimal `ContextLoader` SPI. Specifically, a
|
|
|
|
|
`SmartContextLoader` can choose to process resource locations, component classes,
|
|
|
|
|
or context initializers. Furthermore, a `SmartContextLoader` can set active bean
|
|
|
|
|
definition profiles and test property sources in the context that it loads.
|
|
|
|
|
`SmartContextLoader` is an extension of the `ContextLoader` interface that supersedes the
|
|
|
|
|
original minimal `ContextLoader` SPI. Specifically, a `SmartContextLoader` can choose to
|
|
|
|
|
process resource locations, component classes, or context initializers. Furthermore, a
|
|
|
|
|
`SmartContextLoader` can set active bean definition profiles and test property sources in
|
|
|
|
|
the context that it loads.
|
|
|
|
|
|
|
|
|
|
Spring provides the following implementations:
|
|
|
|
|
|
|
|
|
|
@@ -2316,8 +2316,8 @@ for details and examples.
|
|
|
|
|
|
|
|
|
|
Registering `TestExecutionListener` implementations by using `@TestExecutionListeners` is
|
|
|
|
|
suitable for custom listeners that are used in limited testing scenarios. However, it can
|
|
|
|
|
become cumbersome if a custom listener needs to be used across a test suite. Since Spring
|
|
|
|
|
Framework 4.1, this issue is addressed through support for automatic discovery of default
|
|
|
|
|
become cumbersome if a custom listener needs to be used across an entire test suite. This
|
|
|
|
|
issue is addressed through support for automatic discovery of default
|
|
|
|
|
`TestExecutionListener` implementations through the `SpringFactoriesLoader` mechanism.
|
|
|
|
|
|
|
|
|
|
Specifically, the `spring-test` module declares all core default `TestExecutionListener`
|
|
|
|
|
@@ -2391,9 +2391,9 @@ which listeners are registered by default. Moreover, the set of default listener
|
|
|
|
|
change from release to release -- for example, `SqlScriptsTestExecutionListener` was
|
|
|
|
|
introduced in Spring Framework 4.1, and `DirtiesContextBeforeModesTestExecutionListener`
|
|
|
|
|
was introduced in Spring Framework 4.2. Furthermore, third-party frameworks like Spring
|
|
|
|
|
Security register their own default `TestExecutionListener` implementations by using
|
|
|
|
|
the aforementioned <<testcontext-tel-config-automatic-discovery, automatic discovery
|
|
|
|
|
mechanism>>.
|
|
|
|
|
Boot and Spring Security register their own default `TestExecutionListener`
|
|
|
|
|
implementations by using the aforementioned <<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`.
|
|
|
|
|
@@ -3228,12 +3228,11 @@ extend another and use both its own initializer and the superclass's initializer
|
|
|
|
|
[[testcontext-ctx-management-env-profiles]]
|
|
|
|
|
===== Context Configuration with Environment Profiles
|
|
|
|
|
|
|
|
|
|
Spring 3.1 introduced first-class support in the framework for the notion of environments
|
|
|
|
|
and profiles (AKA "`bean definition profiles`"), and integration tests can be configured
|
|
|
|
|
to activate particular bean definition profiles for various testing scenarios. This is
|
|
|
|
|
achieved by annotating a test class with the `@ActiveProfiles` annotation and supplying a
|
|
|
|
|
list of profiles that should be activated when loading the `ApplicationContext` for the
|
|
|
|
|
test.
|
|
|
|
|
The Spring Framework has first-class support for the notion of environments and profiles
|
|
|
|
|
(AKA "bean definition profiles"), and integration tests can be configured to activate
|
|
|
|
|
particular bean definition profiles for various testing scenarios. This is achieved by
|
|
|
|
|
annotating a test class with the `@ActiveProfiles` annotation and supplying a list of
|
|
|
|
|
profiles that should be activated when loading the `ApplicationContext` for the test.
|
|
|
|
|
|
|
|
|
|
NOTE: You can use `@ActiveProfiles` with any implementation of the `SmartContextLoader`
|
|
|
|
|
SPI, but `@ActiveProfiles` is not supported with implementations of the older
|
|
|
|
|
@@ -3708,14 +3707,13 @@ The following example demonstrates how to implement and register a custom
|
|
|
|
|
[[testcontext-ctx-management-property-sources]]
|
|
|
|
|
===== Context Configuration with Test Property Sources
|
|
|
|
|
|
|
|
|
|
Spring 3.1 introduced first-class support in the framework for the notion of an
|
|
|
|
|
environment with a hierarchy of property sources. Since Spring 4.1, you can configure
|
|
|
|
|
integration tests with test-specific property sources. In contrast to the
|
|
|
|
|
`@PropertySource` annotation used on `@Configuration` classes, you can declare the
|
|
|
|
|
`@TestPropertySource` annotation on a test class to declare resource locations for test
|
|
|
|
|
properties files or inlined properties. These test property sources are added to the set
|
|
|
|
|
of `PropertySources` in the `Environment` for the `ApplicationContext` loaded for the
|
|
|
|
|
annotated integration test.
|
|
|
|
|
The Spring Framework has first-class support for the notion of an environment with a
|
|
|
|
|
hierarchy of property sources, and you can configure integration tests with test-specific
|
|
|
|
|
property sources. In contrast to the `@PropertySource` annotation used on
|
|
|
|
|
`@Configuration` classes, you can declare the `@TestPropertySource` annotation on a test
|
|
|
|
|
class to declare resource locations for test properties files or inlined properties.
|
|
|
|
|
These test property sources are added to the set of `PropertySources` in the
|
|
|
|
|
`Environment` for the `ApplicationContext` loaded for the annotated integration test.
|
|
|
|
|
|
|
|
|
|
[NOTE]
|
|
|
|
|
====
|
|
|
|
|
@@ -3969,7 +3967,6 @@ to define properties in both a subclass and its superclass by using inline prope
|
|
|
|
|
[[testcontext-ctx-management-web]]
|
|
|
|
|
===== Loading a `WebApplicationContext`
|
|
|
|
|
|
|
|
|
|
Spring 3.2 introduced support for loading a `WebApplicationContext` in integration tests.
|
|
|
|
|
To instruct the TestContext framework to load a `WebApplicationContext` instead of a
|
|
|
|
|
standard `ApplicationContext`, you can annotate the respective test class with
|
|
|
|
|
`@WebAppConfiguration`.
|
|
|
|
|
@@ -4111,7 +4108,7 @@ Contrast the comments in this example with the previous example.
|
|
|
|
|
|
|
|
|
|
.[[testcontext-ctx-management-web-mocks]]Working with Web Mocks
|
|
|
|
|
--
|
|
|
|
|
To provide comprehensive web testing support, Spring 3.2 introduced a
|
|
|
|
|
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`>>
|
|
|
|
|
sets up default thread-local state by using Spring Web's `RequestContextHolder` before
|
|
|
|
|
@@ -4241,12 +4238,12 @@ cannot cache application contexts between test classes, and the build process ru
|
|
|
|
|
significantly more slowly as a result.
|
|
|
|
|
====
|
|
|
|
|
|
|
|
|
|
Since Spring Framework 4.3, the size of the context cache is bounded with a default
|
|
|
|
|
maximum size of 32. Whenever the maximum size is reached, a least recently used (LRU)
|
|
|
|
|
eviction policy is used to evict and 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
|
|
|
|
|
programmatically by using the `SpringProperties` API.
|
|
|
|
|
The size of the context cache is bounded with a default maximum size of 32. Whenever the
|
|
|
|
|
maximum size is reached, a least recently used (LRU) eviction policy is used to evict and
|
|
|
|
|
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 programmatically by using the
|
|
|
|
|
`SpringProperties` API.
|
|
|
|
|
|
|
|
|
|
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 execute, it is often beneficial to
|
|
|
|
|
@@ -4279,15 +4276,14 @@ components. Another use case can be found in Spring Batch applications, where yo
|
|
|
|
|
have a parent context that provides configuration for shared batch infrastructure and a
|
|
|
|
|
child context for the configuration of a specific batch job.
|
|
|
|
|
|
|
|
|
|
Since Spring Framework 3.2.2, you can write integration tests that use context
|
|
|
|
|
hierarchies by declaring context configuration with the `@ContextHierarchy` annotation,
|
|
|
|
|
either on an individual test class or within a test class hierarchy. If a context
|
|
|
|
|
hierarchy is declared on multiple classes within a test class hierarchy, you can also
|
|
|
|
|
merge or override the context configuration for a specific, named level in the context
|
|
|
|
|
hierarchy. When merging configuration for a given level in the hierarchy, the
|
|
|
|
|
configuration resource type (that is, XML configuration files or component classes) must
|
|
|
|
|
be consistent. Otherwise, it is perfectly acceptable to have different levels in a
|
|
|
|
|
context hierarchy configured using different resource types.
|
|
|
|
|
You can write integration tests that use context hierarchies by declaring context
|
|
|
|
|
configuration with the `@ContextHierarchy` annotation, either on an individual test class
|
|
|
|
|
or within a test class hierarchy. If a context hierarchy is declared on multiple classes
|
|
|
|
|
within a test class hierarchy, you can also merge or override the context configuration
|
|
|
|
|
for a specific, named level in the context hierarchy. When merging configuration for a
|
|
|
|
|
given level in the hierarchy, the configuration resource type (that is, XML configuration
|
|
|
|
|
files or component classes) must be consistent. Otherwise, it is perfectly acceptable to
|
|
|
|
|
have different levels in a context hierarchy configured using different resource types.
|
|
|
|
|
|
|
|
|
|
The remaining JUnit Jupiter based examples in this section show common configuration
|
|
|
|
|
scenarios for integration tests that require the use of context hierarchies.
|
|
|
|
|
@@ -4509,9 +4505,9 @@ 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
|
|
|
|
|
approach for those particular beans. In that case, you can use `@Autowired` in
|
|
|
|
|
conjunction with `@Qualifier`. As of Spring 3.0, you can also choose to use `@Inject` in
|
|
|
|
|
conjunction with `@Named`. Alternatively, if your test class has access to its
|
|
|
|
|
`ApplicationContext`, you can perform an explicit lookup by using (for example) a call to
|
|
|
|
|
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
|
|
|
|
|
can perform an explicit lookup by using (for example) a call to
|
|
|
|
|
`applicationContext.getBean("titleRepository", TitleRepository.class)`.
|
|
|
|
|
|
|
|
|
|
If you do not want dependency injection applied to your test instances, do not annotate
|
|
|
|
|
@@ -4704,8 +4700,8 @@ bean by name there (as shown earlier, assuming that `myDataSource` is the bean `
|
|
|
|
|
==== Testing Request- and Session-scoped Beans
|
|
|
|
|
|
|
|
|
|
Spring has supported <<core#beans-factory-scopes-other, Request- and session-scoped
|
|
|
|
|
beans>> since the early years. Since Spring 3.2, you can test your request-scoped and
|
|
|
|
|
session-scoped beans by following these steps:
|
|
|
|
|
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
|
|
|
|
|
class with `@WebAppConfiguration`.
|
|
|
|
|
@@ -5066,12 +5062,12 @@ via the `@Commit` and `@Rollback` annotations. See the corresponding entries in
|
|
|
|
|
[[testcontext-tx-programmatic-tx-mgt]]
|
|
|
|
|
===== Programmatic Transaction Management
|
|
|
|
|
|
|
|
|
|
Since Spring Framework 4.1, you can interact with test-managed transactions
|
|
|
|
|
programmatically by using the static methods in `TestTransaction`. For example, you can
|
|
|
|
|
use `TestTransaction` within test methods, before methods, and after methods to start or
|
|
|
|
|
end the current test-managed transaction or to configure the current test-managed
|
|
|
|
|
transaction for rollback or commit. Support for `TestTransaction` is automatically
|
|
|
|
|
available whenever the `TransactionalTestExecutionListener` is enabled.
|
|
|
|
|
You can interact with test-managed transactions programmatically by using the static
|
|
|
|
|
methods in `TestTransaction`. For example, you can use `TestTransaction` within test
|
|
|
|
|
methods, before methods, and after methods to start or end the current test-managed
|
|
|
|
|
transaction or to configure the current test-managed transaction for rollback or commit.
|
|
|
|
|
Support for `TestTransaction` is automatically available whenever the
|
|
|
|
|
`TransactionalTestExecutionListener` is enabled.
|
|
|
|
|
|
|
|
|
|
The following example demonstrates some of the features of `TestTransaction`. See the
|
|
|
|
|
javadoc for {api-spring-framework}/test/context/transaction/TestTransaction.html[`TestTransaction`]
|
|
|
|
|
@@ -5785,7 +5781,7 @@ via `@SqlMergeMode(OVERRIDE)`. Consult the <<spring-testing-annotation-sqlmergem
|
|
|
|
|
[[testcontext-parallel-test-execution]]
|
|
|
|
|
==== Parallel Test Execution
|
|
|
|
|
|
|
|
|
|
Spring Framework 5.0 introduces basic support for executing tests in parallel within a
|
|
|
|
|
Spring Framework 5.0 introduced basic support for executing tests in parallel within a
|
|
|
|
|
single JVM when using the Spring TestContext Framework. In general, this means that most
|
|
|
|
|
test classes or test methods can be executed in parallel without any changes to test code
|
|
|
|
|
or configuration.
|
|
|
|
|
@@ -5800,12 +5796,13 @@ for when not to execute tests in parallel.
|
|
|
|
|
|
|
|
|
|
Do not execute tests in parallel if the tests:
|
|
|
|
|
|
|
|
|
|
* Use Spring's `@DirtiesContext` support.
|
|
|
|
|
* Use Spring Framework's `@DirtiesContext` support.
|
|
|
|
|
* Use Spring Boot's `@MockBean` or `@SpyBean` support.
|
|
|
|
|
* Use JUnit 4's `@FixMethodOrder` support or any testing framework feature
|
|
|
|
|
that is designed to ensure that test methods run in a particular order. Note,
|
|
|
|
|
however, that this does not apply if entire test classes are executed in parallel.
|
|
|
|
|
* Change the state of shared services or systems such as a database, message broker,
|
|
|
|
|
filesystem, and others. This applies to both in-memory and external systems.
|
|
|
|
|
filesystem, and others. This applies to both embedded and external systems.
|
|
|
|
|
|
|
|
|
|
[TIP]
|
|
|
|
|
====
|
|
|
|
|
@@ -6903,13 +6900,13 @@ request. You can do so as follows, where `print()` is a static import from
|
|
|
|
|
----
|
|
|
|
|
|
|
|
|
|
As long as request processing does not cause an unhandled exception, the `print()` method
|
|
|
|
|
prints all the available result data to `System.out`. Spring Framework 4.2 introduced a
|
|
|
|
|
`log()` method and two additional variants of the `print()` method, one that accepts an
|
|
|
|
|
`OutputStream` and one that accepts a `Writer`. For example, invoking `print(System.err)`
|
|
|
|
|
prints the result data to `System.err`, while invoking `print(myWriter)` prints the
|
|
|
|
|
result data to a custom writer. If you want to have the result data logged instead of
|
|
|
|
|
printed, you can invoke the `log()` method, which logs the result data as a single
|
|
|
|
|
`DEBUG` message under the `org.springframework.test.web.servlet.result` logging category.
|
|
|
|
|
prints all the available result data to `System.out`. There is also a `log()` method and
|
|
|
|
|
two additional variants of the `print()` method, one that accepts an `OutputStream` and
|
|
|
|
|
one that accepts a `Writer`. For example, invoking `print(System.err)` prints the result
|
|
|
|
|
data to `System.err`, while invoking `print(myWriter)` prints the result data to a custom
|
|
|
|
|
writer. If you want to have the result data logged instead of printed, you can invoke the
|
|
|
|
|
`log()` method, which logs the result data as a single `DEBUG` message under the
|
|
|
|
|
`org.springframework.test.web.servlet.result` logging category.
|
|
|
|
|
|
|
|
|
|
In some cases, you may want to get direct access to the result and verify something that
|
|
|
|
|
cannot be verified otherwise. This can be achieved by appending `.andReturn()` after all
|
|
|
|
|
|
Sam Brannen