unit-testing - 像往常一样对 docker 容器或 dockerize 测试运行测试？

Question

我是 Docker 新手，正在阅读 Docker。这是在独立且可重现的标准化配置中测试系统的好方法(如果操作正确)。

但是，在我阅读的所有内容中，似乎并没有过多强调应该如何使用 docker 容器进行测试。 docker 用于“包含”基础设施和应用程序(代码)，以便于测试(以及部署)。但有时测试代码库很大，也不是那么简单。一个人可以有一个测试代码库用于 API 测试，另一个用于 UI 等。

测试 Docker 容器/应用程序/基础设施的部署的标准做法是什么，或者应该是什么？应该:

• 测试代码以旧的传统方式部署，作为您从某个地方提取的文件存储库，然后在 Jenkins 服务器/从属或本地主机上运行以进行开发/QA 测试/调试，测试针对 docker 容器中的应用程序？
• 将整个测试代码库 dockerize 为一个独立的容器，然后使用该容器针对具有应用代码/系统基础架构的其他容器启动/执行测试？
• 将测试组合为各个 docker 容器本身的一部分，以便在需要时/根据需要运行。但我认为这仅适用于真正与包含匹配应用程序代码的容器配对的单元测试。集成、UI、系统级测试与系统内应用模块的关联不同。

我能想到的使 dockerizing 测试可能有用的唯一原因是它是一个容器，包含您需要的所有测试和匹配的测试基础设施(所有测试平台/语言依赖项)，因此可以部署和运行测试与匹配的应用程序代码容器一起在任何地方。无需在需要时/根据需要设置测试基础架构。但似乎没有人在博客上写过这样的 dockerized 测试。

Answer 1

我更喜欢您的选项 (3)，即在生产可部署工件(docker 镜像)中包含测试代码

将引用 Alister Scott来自 GTAC 2015我参加了:

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 测试，即需要使用超过 1 个 docker 镜像的测试，我更喜欢 CI tool那个，通过docker-compose ，以及用于这些测试的单独 git 存储库，协调创建大型测试所需的所有容器。再次使用 docker 图像 should be the exact same as for production除了 what varies is the configuration (例如环境变量)使测试指向测试数据和/或暂存服务。