Move Testcontainers documentation from howto to features

Closes gh-35018
This commit is contained in:
Phillip Webb 2023-04-16 21:20:22 -07:00
parent 81a972af8d
commit 1a0b9bdcd0
9 changed files with 112 additions and 107 deletions

View File

@ -1013,3 +1013,7 @@ data.nosql.elasticsearch.connecting-using-rest.webclient=data.nosql.elasticsearc
getting-started.first-application.code.enable-auto-configuration=getting-started.first-application.code.spring-boot-application
actuator.tracing=actuator.http-exchanges
actuator.tracing.custom=actuator.http-exchanges.custom
# Spring Boot 3.0 - 3.1 migrations
howto.testing.testcontainers=features.testing.testcontainers
howto.testing.testcontainers.dynamic-properties=features.testing.testcontainers.dynamic-properties

View File

@ -902,6 +902,108 @@ See https://spockframework.org/spock/docs/2.2-M1/modules.html#_spring_module[the
[[features.testing.testcontainers]]
=== Testcontainers
The https://www.testcontainers.org/[Testcontainers] library provides a way to manage services running inside Docker containers.
It integrates with JUnit, allowing you to write a test class that can start up a container before any of the tests run.
Testcontainers is especially useful for writing integration tests that talk to a real backend service such as MySQL, MongoDB, Cassandra and others.
Testcontainers can be used in a Spring Boot test as follows:
include::code:vanilla/MyIntegrationTests[]
This will start up a docker container running Neo4j (if Docker is running locally) before any of the tests are run.
In most cases, you will need to configure the application to connect to the service running in the container.
[[features.testing.testcontainers.service-connections]]
==== Service Connections
A service connection is a connection to any remote service.
Spring Boot's auto-configuration can consume the details of a service connection and use them to establish a connection to a remote service.
When doing so, the connection details take precedence over any connection-related configuration properties.
When using Testcontainers, connection details can be automatically created for a service running in a container by annotating the container field in the test class.
include::code:MyIntegrationTests[]
Thanks to `@ServiceConnection`, the above configuration allows Neo4j-related beans in the application to communicate with Neo4j running inside the Testcontainers-managed Docker container.
This is done by automatically defining a `Neo4jConnectionDetails` bean which is then used by the Neo4j auto-configuration, overriding any connection-related configuration properties.
Service connection annotations are processed by `ContainerConnectionDetailsFactory` classes registered with `spring.factories`.
A `ContainerConnectionDetailsFactory` can create a `ConnectionDetails` bean based on a specific `Container` subclass, or the Docker image name.
The following service connection factories are provided in the `spring-boot-testcontainers` jar:
|===
| Connection Details | Matched on
| `CassandraConnectionDetails`
| Containers of type `CassandraContainer`
| `CouchbaseConnectionDetails`
| Containers of type `CouchbaseContainer`
| `ElasticsearchConnectionDetails`
| Containers of type `ElasticsearchContainer`
| `FlywayConnectionDetails`
| Containers of type `JdbcDatabaseContainer`
| `InfluxDbConnectionDetails`
| Containers of type `InfluxDBContainer`
| `JdbcConnectionDetails`
| Containers of type `JdbcDatabaseContainer`
| `KafkaConnectionDetails`
| Containers of type `KafkaContainer`
| `LiquibaseConnectionDetails`
| Containers of type `JdbcDatabaseContainer`
| `MongoConnectionDetails`
| Containers of type `MongoDBContainer`
| `Neo4jConnectionDetails`
| Containers of type `Neo4jContainer`
| `R2dbcConnectionDetails`
| Containers of type `MariaDBContainer`, `MSSQLServerContainer`, `MySQLContainer` or `PostgreSQLContainer`
| `RabbitConnectionDetails`
| Containers of type `RabbitMQContainer`
| `RedisConnectionDetails`
| Containers named "redis"
|===
[TIP]
====
By default all applicable connection details beans will be created for a given `Container`.
For example, a `PostgreSQLContainer` will create both `JdbcConnectionDetails` and `R2dbcConnectionDetails`.
If you want to create only a subset of the applicable types, you can use the `type` attribute of `@ServiceConnection`.
====
By default `Container.getDockerImageName()` is used to obtain the name used to find connection details.
If you are using a custom docker image, you can use the `name` attribute of `@ServiceConnection` to override it.
For example, if you have a `GenericContainer` using a Docker image of `registry.mycompany.com/mirror/myredis`, you'd use `@ServiceConnection(name="redis")` to ensure `RedisConnectionDetails` are created.
[[features.testing.testcontainers.dynamic-properties]]
==== Dynamic Properties
A slightly more verbose but also more flexible alternative to service connections is `@DynamicPropertySource`.
A static `@DynamicPropertySource` method allows adding dynamic property values to the Spring Environment.
include::code:MyIntegrationTests[]
The above configuration allows Neo4j-related beans in the application to communicate with Neo4j running inside the Testcontainers-managed Docker container.
[[features.testing.utilities]]
=== Test Utilities
A few test utility classes that are generally useful when testing your application are packaged as part of `spring-boot`.

View File

@ -18,107 +18,6 @@ For additional details on Spring Security's testing support, see Spring Security
[[howto.testing.testcontainers]]
=== Use Testcontainers for Integration Testing
The https://www.testcontainers.org/[Testcontainers] library provides a way to manage services running inside Docker containers.
It integrates with JUnit, allowing you to write a test class that can start up a container before any of the tests run.
Testcontainers is especially useful for writing integration tests that talk to a real backend service such as MySQL, MongoDB, Cassandra and others.
Testcontainers can be used in a Spring Boot test as follows:
include::code:vanilla/MyIntegrationTests[]
This will start up a docker container running Neo4j (if Docker is running locally) before any of the tests are run.
In most cases, you will need to configure the application to connect to the service running in the container.
[[howto.testing.testcontainers.service-connections]]
==== Service Connections
A service connection is a connection to any remote service.
Spring Boot's auto-configuration can consume the details of a service connection and use them to establish a connection to a remote service.
When doing so, the connection details take precedence over any connection-related configuration properties.
When using Testcontainers, connection details can be automatically created for a service running in a container by annotating the container field in the test class.
include::code:MyIntegrationTests[]
Thanks to `@ServiceConnection`, the above configuration allows Neo4j-related beans in the application to communicate with Neo4j running inside the Testcontainers-managed Docker container.
This is done by automatically defining a `Neo4jConnectionDetails` bean which is then used by the Neo4j auto-configuration, overriding any connection-related configuration properties.
Service connection annotations are processed by `ContainerConnectionDetailsFactory` classes registered with `spring.factories`.
A `ContainerConnectionDetailsFactory` can create a `ConnectionDetails` bean based on a specific `Container` subclass, or the Docker image name.
The following service connection factories are provided in the `spring-boot-testcontainers` jar:
|===
| Connection Details | Matched on
| `CassandraConnectionDetails`
| Containers of type `CassandraContainer`
| `CouchbaseConnectionDetails`
| Containers of type `CouchbaseContainer`
| `ElasticsearchConnectionDetails`
| Containers of type `ElasticsearchContainer`
| `FlywayConnectionDetails`
| Containers of type `JdbcDatabaseContainer`
| `InfluxDbConnectionDetails`
| Containers of type `InfluxDBContainer`
| `JdbcConnectionDetails`
| Containers of type `JdbcDatabaseContainer`
| `KafkaConnectionDetails`
| Containers of type `KafkaContainer`
| `LiquibaseConnectionDetails`
| Containers of type `JdbcDatabaseContainer`
| `MongoConnectionDetails`
| Containers of type `MongoDBContainer`
| `Neo4jConnectionDetails`
| Containers of type `Neo4jContainer`
| `R2dbcConnectionDetails`
| Containers of type `MariaDBContainer`, `MSSQLServerContainer`, `MySQLContainer` or `PostgreSQLContainer`
| `RabbitConnectionDetails`
| Containers of type `RabbitMQContainer`
| `RedisConnectionDetails`
| Containers named "redis"
|===
[TIP]
====
By default all applicable connection details beans will be created for a given `Container`.
For example, a `PostgreSQLContainer` will create both `JdbcConnectionDetails` and `R2dbcConnectionDetails`.
If you want to create only a subset of the applicable types, you can use the `type` attribute of `@ServiceConnection`.
====
By default `Container.getDockerImageName()` is used to obtain the name used to find connection details.
If you are using a custom docker image, you can use the `name` attribute of `@ServiceConnection` to override it.
For example, if you have a `GenericContainer` using a Docker image of `registry.mycompany.com/mirror/myredis`, you'd use `@ServiceConnection(name="redis")` to ensure `RedisConnectionDetails` are created.
[[howto.testing.testcontainers.dynamic-properties]]
==== Dynamic Properties
A slightly more verbose but also more flexible alternative to service connections is `@DynamicPropertySource`.
A static `@DynamicPropertySource` method allows adding dynamic property values to the Spring Environment.
include::code:/MyIntegrationTests[]
The above configuration allows Neo4j-related beans in the application to communicate with Neo4j running inside the Testcontainers-managed Docker container.
[[howto.testing.slice-tests]]
=== Structure `@Configuration` classes for inclusion in slice tests

View File

@ -14,7 +14,7 @@
* limitations under the License.
*/
package org.springframework.boot.docs.howto.testing.testcontainers.dynamicproperties;
package org.springframework.boot.docs.features.testing.testcontainers.dynamicproperties;
import org.junit.jupiter.api.Test;
import org.testcontainers.containers.Neo4jContainer;

View File

@ -14,7 +14,7 @@
* limitations under the License.
*/
package org.springframework.boot.docs.howto.testing.testcontainers.serviceconnections;
package org.springframework.boot.docs.features.testing.testcontainers.serviceconnections;
import org.junit.jupiter.api.Test;
import org.testcontainers.containers.Neo4jContainer;

View File

@ -14,7 +14,7 @@
* limitations under the License.
*/
package org.springframework.boot.docs.howto.testing.testcontainers.vanilla;
package org.springframework.boot.docs.features.testing.testcontainers.vanilla;
import org.junit.jupiter.api.Test;
import org.testcontainers.containers.Neo4jContainer;

View File

@ -14,7 +14,7 @@
* limitations under the License.
*/
package org.springframework.boot.docs.howto.testing.testcontainers.dynamicproperties
package org.springframework.boot.docs.features.testing.testcontainers.dynamicproperties
import org.junit.jupiter.api.Test
import org.springframework.boot.test.context.SpringBootTest

View File

@ -14,7 +14,7 @@
* limitations under the License.
*/
package org.springframework.boot.docs.howto.testing.testcontainers.serviceconnection
package org.springframework.boot.docs.features.testing.testcontainers.serviceconnections
import org.junit.jupiter.api.Test
import org.testcontainers.containers.Neo4jContainer

View File

@ -14,7 +14,7 @@
* limitations under the License.
*/
package org.springframework.boot.docs.howto.testing.testcontainers.vanilla
package org.springframework.boot.docs.features.testing.testcontainers.vanilla
import org.junit.jupiter.api.Test
import org.springframework.boot.test.context.SpringBootTest