If you develop services using Spring Boot and maybe Spring Cloud and you domedium sized tests during build process, then this set ofSpring Boot auto-configurations might be handy. By adding module into classpath, you will get stateful service,like Couchbase or Kafka, auto-started and available for connection from your application service w/o wiring anyadditional code. Docker and TestContainers are used tobootstrap stateful service using Spring Cloud bootstrap phase.Usage of Spring Cloud in your production code is optional, but you will need it in tests. See How to use below.
Install Docker on your machine
Make sure you have Spring Boot and Spring Cloud in classpath of your tests.In case if you need to pick version.
<project>
...
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bootstrap</artifactId>
<!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-bootstrap -->
<version>[pick version]</version>
</dependency>
...
</project>
Note
|
testcontainers-spring-boot project migrated to Spring Boot 2.4 in 2.0.0 version.Please note, that in order to use this project with Spring Boot 2.4, you need to use spring-cloud-starter-bootstrap dependency.For earlier Spring Boot (prior to 2.4) users — you need to use spring-cloud-starter dependency instead. |
If you do not use Spring Cloud - make it work for tests only:
<project>
...
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
<!-- https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter -->
<version>[pick version]</version>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bootstrap</artifactId>
<!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-bootstrap -->
<version>[pick version]</version>
<scope>test</scope>
</dependency>
...
</project>
Add data service library:
<project>
...
<dependency>
<groupId>com.playtika.testcontainers</groupId>
<artifactId>embedded-kafka</artifactId>
<!-- https://mvnrepository.com/artifact/com.playtika.testcontainers/ -->
<version>[pick version]</version>
<scope>test</scope>
</dependency>
...
</project>
Use produced properties in your configuration.
Example:
spring.kafka.bootstrap-servers=${embedded.kafka.brokerList}
embedded.kafka.topicsToCreate=some_topic
embedded.containers.forceShutdown=true //default is false
Note
|
Otherwise, it will be shutdown with delay, see https://github.com/testcontainers/moby-ryuk |
embedded.containers.enabled=true //default is true
Note
|
If you setup, for example embedded.kafka.enabled + embedded.containers.enabled, result will be same as using AND between two booleans. |
Note
|
embedded.kafka.enabled=false will cause DockerNotPresentException if you don’t have docker installed. But embedded.containers.enabled=false won’t cause any exceptions in this case. |
Setting1 | Setting2 | Outcome |
---|---|---|
embedded.containers.enabled=false |
embedded.memsql.enabled=true |
Memsql will not start |
embedded.containers.enabled=true |
embedded.memsql.enabled=false |
Memsql will not start |
embedded.containers.enabled=true |
embedded.memsql.enabled=true |
Memsql will start |
embedded.containers.enabled is missing |
embedded.memsql.enabled is missing |
Memsql will start |
Setting name | Default value | Description |
---|---|---|
embedded.{module-name}.waitTimeoutInSeconds |
60 |
Waiting time for a container to start in seconds |
embedded.{module-name}.enabled |
true |
Enables a container to be started on startup |
embedded.{module-name}.reuseContainer |
false |
Enables a reuse container testcontainers feature. |
embedded.{module-name}.command |
null |
List of keywords which combines into command for container startup. Some modules ship container’s commands by default, so resetting this value may lead to incorrect work of container. |
embedded.{module-name}.env |
null |
key-value map of additional environment variables. Where key is name of variable and value is actual value of it. |
embedded.{module-name}.filesToInclude |
empty list |
List of files to include objects.Each object should have two parameters:
Example: embedded.redis.filesToInclude:
classpathResource: "/my_local_file.txt"
containerPath: "/etc/path_in_container.txt"
|
embedded.{module-name}.mountVolumes |
empty list |
List of mount volumes to persist between container restarts.Each object should have three parameters:
Example: embedded.postgresql.mountVolumes:
hostPath: "pgdata"
containerPath: "/var/lib/postgresql/data"
mode: READ_WRITE
|
embedded.{module-name}.capabilities |
empty list. |
The Linux capabilities that should be enabled. You can disable all capabilities by providing empty value for this property.See: https://man7.org/linux/man-pages/man7/capabilities.7.html.Available values can be taken from |
There are 2 branches in project: master
and develop
You need to fork project and create branch from develop
You do not need to update project version in pom.xml
files, this will be done by release job
Once finished - create pull request to develop
from your fork, pass review and wait for merge
On release, ci job will merge develop
into master
and remove snapshot + publish artifacts into public maven repo
Naming/formatting patterns match existing code
Test for success scenario
Test for negative scenario (autoconfiguration is disabled via properties). How to test autoconfiguration
Add new module to testcontainers-spring-boot-bom
Module provides documentation in README.adoc
and this documentation is included in parent README.adoc
(see an example in already existing modules). Documentation should include:
maven module declaration
consumed properties
produced properties
notes (if applicable)
example of usage
Release build is done using gitflow-maven-plugin
Release is done per each major change, critical bug
Release can be done by contributor request
Contacts to start release:
一、背景 SpringBoot进行单元测试的时候,基本上都离不开MySQL,而单元测试应该是不依赖于任何环境的,所以最初我们采用的单元测试的方法是mock组件的方式。如今随着docker技术越来越成熟,现在用在单元测试方面也变得更加方便。 Testcontainers Testcontainers是github开源组件,是利用本地启动docker容器的方式来替代环境中的组件,目前支持的组件有,my
TestContainers太棒了! 它提供了一种非常方便的方式来启动和清除JUnit测试中的Docker容器。 此功能对于将应用程序与实际数据库以及可使用docker映像的任何其他资源进行集成测试非常有用。 我的目标是演示使用TestContainers对基于JPA的Spring Boot Application进行示例测试。 该示例基于TestContainer github repo上的示例
IDEA 创建 Spring Boot 项目时可选依赖说明 一、Developer Tools Spring Native [Experimental] 提供 GraalVM 编译支持,GraalVM 是一个编译器,实验版。 Spring Boot DevTools 提供快速应用程序重启、实时加载和配置。 Lombok 它是一个Java注解库,提供一些有用的注解,例如: @Setter :在类或字
Testcontainers是一个Java库,可轻松将Docker容器集成到JUnit测试中。 在Containerized World中 ,将测试配置与嵌入式数据库和服务复杂化几乎没有意义。 而是使用在Docker中运行您的服务,并让Testcontainers为您管理此服务。 在此博客文章中,您将学习如何在Spring Boot 2集成测试中配置Testcontainer以运行PostgreS
Testcontainers Testcontainers is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium web browsers, or anything else that can run in a Doc
相关pom.xml 我的测试类: 我只是在试着测试数据库。 类级别上的@SQL注释不能像我的情况那样与Testcontainers初始化一起工作吗? 这里需要什么使我的两个初始脚本都运行? 我尝试使用.WithInitScript,它运行了。但是,我有很多数据要初始化,而且文件太大(而且会增长),所以我将DDL(模式)和Inserts(数据)分开。现在,我的问题是如何使用“WithInitScri
所以,在我的工作中,我一直试图开始从Maven到Gradle的迁移,但我现在遇到了一个我似乎无法把头绕过去的严重问题。 我基本上只想为我的测试运行一些简单的liquibase迁移,为此我旋转了两个测试容器。一个用于rabbitmqexchange,一个用于postgres DB。 我使用这里描述的一个小变通方法设置了postgres容器:使用Kotlin和Testcontainers测试Sprin
我正在尝试为kafka消息传递设置集成测试,并从使用Embedded-Kafka转向使用TestContainers。给定docker-compose的以下配置和所有集成测试的基类: Kafka-compose.yaml: 我遇到的问题很少: 似乎spring-Kafka和它的在所有可能的用@springboottest注释的测试中都是活动的,而不仅仅是在Kafka特定的测试中。这意味着发送到Ka
我正在尝试对停靠数据库运行DropWizard的集成测试。 DropWizard 测试容器 我试过的: 我得到由:java.lang.IllegalStateException引起的 将这些链接在一起也不起作用 最后,这是可行的,但据我所知,它在每次测试中都运行新的DropwizardAppRule,这是不好的... 那么,如何将规则链接起来,使PostgreSQLContainer首先启动,并且
我在玩Testcontainers、Micronaut和Kotlin,不知何故Micronaut不想替换到我正在启动的MongoDB的动态端口及其目前的工作状态。 我还没有替换 这是我的设置代码: 错误消息:消息:无法解析占位符${MONGO_PORT}