原文地址:https://blog.harrison.dev/2016/06/19/integration-testing-with-docker-compose.html。
集成测试通常是一项困难的活动,特别是在涉及到分布式系统时。即便正在构建单体应用,也可能需要启动数据库,来进行集成测试。这种事情在早期很容易做到,但随着代码库的增加,难度将呈指数级增长。值得庆幸的是,Docker Compose 使我们能够在运行 Docker 的任何环境中,进行集成测试。
假设从一个单体体制开始,拥有一个服务和一个数据库。你可以像 1999 年那样,从源代码构建应用服务和数据库;或使用 brew install 解决所有依赖关系。但最终你的系统看起来是这样的:
待测试端点是 /create
,它做的全部事情是在数据库中存储一些数据。看起来非常简单。因此,可以编写如下 Bash 脚本 - CURL 端点;然后查询数据库(退出码 0 代表成功;退出码 1 代表失败)。该脚本很简单,但最重要的是它有效。
curl http://localhost:8000/create
COUNT = `mysql --user="$user" --password="$password" --database="$database" \
--execute="SELECT COUNT(*) FROM table_name;"`
if [[ $COUNT -ne 1 ]]; then
exit 1
fi
但是有很多隐藏的依赖项:
假设在 Bash 脚本中添加一行,重置数据。
mysql --user="$user" --password="$password" --database="$database" \
--execute="TRUNCATE table table_name"
curl http://localhost:8000/create
COUNT = `mysql --user="$user" --password="$password" --database="$database"\
--execute="SELECT COUNT(*) FROM table_name;"`
if [[ $COUNT -ne 1 ]]; then
exit 1
fi
这样做可以消除最后一个隐藏依赖项(数据库中存在数据),但也带来非常严重的副作用,因为本地开发数据库与测试数据库共享。因此,每次运行集成测试,都会丢失全部开发数据😭。这似乎显而易见,但实际上这种体制仍然存在。然而不一定非要这样做。从此处开始,我将通过一个构建在 Docker Compose 上的示例,解决上面列出的所有问题。在本例中,将使用 Node 作为应用程序框架,使用 RethinkDB 作为数据库,但是你也可以选择其它技术栈。
我们从 Martin Fowler 的微服务测试手册中学习集成测试。我们将在被测试的系统外部启动一个容器,使容器运行一些测试,然后检查测试容器的 run 命令的退出代码。
为清晰起见,下面列出文件结构,因为该项目中有多个 Dockerfile
。
integration-test/
Dockerfile
index.js
package.json
test.sh
docker-compose.yml
index.js
package.json
Dockerfile
接下来走查集成测试的每个组件。
有时丢弃所有数据是好事,在运行测试时,丢弃数据是必要的。使用 Docker compose 实现这一点非常容易,只需启动数据库,无需挂载数据卷。这意味着当销毁容器时,数据也随之消失。还意味着如果不销毁容器,那么可以进入容器内部,对数据库运行查询,进行调试。下面是一个示例 Docker Compose 文件,它只启动一个临时数据库(RethinkDB)。
integration-test/docker-compose.yml
version'2'
services
rethinkdb
image rethinkdb
expose
"28015"
记住这个概念,因为我们很快就会用到它。
下一步是容器化将要测试的应用程序。需要构建/运行应用程序,连接数据库,以及暴露用于测试的端口。
Dockerfile
FROM mhart/alpine-node
WORKDIR /service
COPY package.json .
RUN npm install
COPY index.js .
integration-test/docker-compose.yml
version'2'
services
my-service
build..
command npm start
links
rethinkdb
ports
"8080:8080"
rethinkdb
image rethinkdb
expose
"28015"
此时,可以使用 docker-compose up
检查服务,以及访问 http://localhost:8080(只要你拥有服务器,并且线路已连接)。
现在,我们已拥有数据库和应用程序,接下来构建测试容器。该容器需要向 my-service
上的 /create
端点发送 POST 请求,并且检查数据库中的变更。为实现这一点,这里使用 tape 和 request-promise 检查端点。
integration-test/index.js
import test from 'tape';
import requestPromise from 'request-promise';
const before = test;
const after = test;
const beforeEach = () => {/*test setup*/};
const afterEach = () => {/*test cleanup*/};
before('before', (t) => {/*one time setup*/});
test('POST /create', (t) => {
beforeEach()
.then(() => (
requestPromise({
method: 'POST',
// yes! we can use the service name in the docker-compose.yml file
uri: 'http://my-service:8080/create',
body: {
thing: 'this thing',
},
})
))
.then((response) => {
// inspect the response
t.equal(response.statusCode, 200, 'statusCode: 200');
})
.then(() => (
// inspect the database
rethinkdb.table('table_name')
.filter({
thing: 'this thing',
})
.count()
.run(connection)
.then((value) => {
t.equal(value, 1, 'have data');
})
))
.catch((error) => t.fail(error))
.then(() => afterEach())
.then(() => t.end());
});
after('after', (t) => {/*one time setup*/});
测试 Dockerfile 看起来与应用程序 Dockerfile 相同。
integration-test/Dockerfile
x
FROM mhart/alpine-node
WORKDIR /integration
COPY package.json .
RUN npm install
COPY index.js .
现在,将测试应用程序添加到 docker-compose.yml
文件。
integration-test/docker-compose.yml
version'2'
services
integration-tester
build.
links
my-service
my-service
build..
command npm start
links
rethinkdb
ports
"8080:8080"
rethinkdb
image rethinkdb
expose
"28015"
这里是很酷的部分,当运行 docker-compose up
时,将发生如下事情
my-service
和 integration-tester
容器my-service
、integration-tester
和 rethinkdb
容器integration-tester
运行所有测试,直到停止integration-tester
停止后,docker-compose
关闭所有容器这正是需要在 CI 中运行的集成测试。到目前为止,我们尚未检查 integration-tester
容器的退出码,接下来马上讲述。
在所有自动化工作就绪后,我们需要将所有东西结合起来,并且在测试完成后,执行清理工作。为此,我们使用 docker wait
阻塞脚本,获取测试的退出码。我们使用该退出码输出消息(通过/失败),并且使用相同的退出码退出主脚本。这很有用因为大多数(并非全部)CI 环境使用退出码确定测试成功与否。我们还将获取测试容器的日志,并且将它们打印出来,以便在测试失败时提供上下文。下面是一个(极其冗长的)脚本,它完成我们在本地或 CI 中运行集成测试所需的一切。
integration-test/test.sh
x
# define some colors to use for output
RED='\033[0;31m'
GREEN='\033[0;32m'
NC='\033[0m'
# kill and remove any running containers
cleanup () {
docker-compose -p ci kill
docker-compose -p ci rm -f --all
}
# catch unexpected failures, do cleanup and output an error message
trap 'cleanup ; printf "${RED}Tests Failed For Unexpected Reasons${NC}\n"'\
HUP INT QUIT PIPE TERM
# build and run the composed services
docker-compose -p ci build && docker-compose -p ci up -d
if [ $? -ne 0 ] ; then
printf "${RED}Docker Compose Failed${NC}\n"
exit -1
fi
# wait for the test service to complete and grab the exit code
TEST_EXIT_CODE=`docker wait ci_integration-tester_1`
# output the logs for the test (for clarity)
docker logs ci_integration-tester_1
# inspect the output of the test and display respective message
if [ -z ${TEST_EXIT_CODE+x} ] || [ "$TEST_EXIT_CODE" -ne 0 ] ; then
printf "${RED}Tests Failed${NC} - Exit Code: $TEST_EXIT_CODE\n"
else
printf "${GREEN}Tests Passed${NC}\n"
fi
# call the cleanup fuction
cleanup
# exit the script with the same code as the test service code
exit $TEST_EXIT_CODE
如欲获得完整示例,请查看 auth-service。想要看到它的实际效果,你需要做:
git clone https://github.com/hharnisc/auth-service.git
cd auth-service
npm test
对于更复杂的示例(多层微服务),请查看 login-service。
git clone https://github.com/hharnisc/login-service.git
cd login-service
npm test
这种方式在实践中效果很好,我已经使用该方式为一些微服务执行集成测试。每当我在 CI 中遇到失败时,同样的 Bug 肯定可以在本地复现。我遇到的最大问题是,因为应用程序没有完全启动,而导致的测试失败。为解决该问题,我在应用程序上实现一个 /health
API 端点,并且在测试的 before
块内部添加重试。自从修复该问题后,再没遇到其它古怪的问题,并且一直使用该方式在 CI 中运行集成测试。这真的很有用,并且已经捕获一些可能在部署过程中出现的实际 Bug,我希望你也能发现它有用。