像往常一样对Docker容器运行测试还是对dockerize测试进行测试? [英] Running tests as usual against docker containers or dockerize tests?
问题描述
我是Docker的新手，正在阅读Docker.这是在自包含且可复制的标准化配置(正确完成)中测试系统的好方法.
I'm new to Docker and was reading up on Docker. It's a great way to test systems in a self contained and reproducible standardized configuration (when done correctly).
但是，在我已阅读的所有内容中，似乎并没有过多地强调应该如何使用Docker容器进行测试.泊坞窗用于包含"基础结构和应用程序(代码)，以方便测试(以及部署).但是有时候测试代码库很大，而且不是那么简单.一个可以具有用于API测试的测试代码库，另一个可以用于UI等.
However, in all the things I've read, there doesn't seem to be too much emphasis on how the testing should occur with docker containers. The docker is used to "contain" the infrastructure and application (code) for easy testing (as well as deployment). But sometimes test codebases are be large and not so simple too. And one can have a test codebase for API tests, another for UI, etc.
测试应用程序/基础架构的docker容器/部署的标准做法是(或在某个时候确定)什么是标准做法?应该:
What is or should be (as determined at some point) the standard practice for testing docker containers/deployments of your applications/infrastructure? Should:
- 以旧的传统方式部署测试代码，就像文件存储库从某个地方拉出然后在Jenkins服务器/从属服务器或本地主机上运行以进行dev/qa测试/调试，测试针对docker容器中的应用程序吗?
- 将整个测试代码库作为一个自包含的容器docker化，然后使用该容器针对具有应用程序代码/系统基础结构的其他容器启动/执行测试?
- 将测试作为单独的Docker容器本身的一部分进行组合，以便在需要时/根据需要运行.但是我认为这仅对真正与包含匹配应用程序代码的容器配对的单元测试最有效.集成，UI，系统级测试与系统内的应用程序模块的关联有所不同.
我认为使dockerizing测试可能有用的唯一原因是，它是一个容器，其中包含您需要的所有测试以及匹配的测试基础结构(所有测试平台/语言依赖性)，以便可以部署和运行测试随处可见，以及匹配的应用代码容器.无需在需要时/根据需要设置测试基础结构.但是似乎没有关于dockerized测试这样的事情的博客.
The only reason I can think of that make dockerizing tests perhaps useful is that it's a single container with all the tests you need and the matching test infrastructure (all the test platform/language dependencies) so that one can deploy and run tests anywhere together with the matching app code containers. Saves one from having to set up test infrastructure when/as needed. But no seems to have blogged about such a thing for dockerized tests.
推荐答案
我更喜欢您的选择(3)，即在生产可部署的工件(docker映像)中包含测试代码
I prefer your option (3) i.e. to include test code in the production deployable artifact (the docker image)
将引用
Will quote Alister Scott from GTAC 2015 which I attended:
不要害怕在您的应用程序中添加不具有功能性目的的可测试性特定功能.最近，我不得不在汽车上安装新轮胎，并意识到许多轮胎具有称为胎面指示器的可测试性.这些不是出于功能目的
Don’t be afraid to add testability specific features to your app that don’t serve a functional purpose. I recently had to get new tyres on my car and realized that a lot of tyres have testability features called tread indicators. These don’t serve a functional purpose
对于集成和e2e测试，即需要使用多个docker镜像的测试，我更喜欢 CI工具，它通过 docker-compose ，以及用于这些测试的单独git repo进行编排创建较大测试所需的所有容器.再次使用使用的docker映像应与生产版本完全相同，除了
For integration and e2e tests, i.e. tests that require more than 1 docker image to be used, I prefer CI tool that, through docker-compose, and a separate git repo for these tests, orchestrates the creation of all containers that are needed for the larger test. Again the docker images used should be the exact same as for production except what varies is the configuration (e.g. environment variables) that make the tests point to test data and/or staging services.
这篇关于像往常一样对Docker容器运行测试还是对dockerize测试进行测试?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
