Move Testcontainers documentation from howto to features
Closes gh-35018
This commit is contained in:
parent
81a972af8d
commit
1a0b9bdcd0
|
@ -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
|
||||
|
|
|
@ -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`.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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;
|
|
@ -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;
|
|
@ -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;
|
|
@ -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
|
|
@ -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
|
|
@ -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
|
Loading…
Reference in New Issue