照常针对 docker 容器运行测试或 dockerize 测试？

我是 Docker 新手，正在阅读有关 Docker 的文章。这是在独立且可重复的标准化配置（正确完成时）中测试系统的好方法。

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

什么是或应该是（在某些时候确定）测试 docker 容器/应用程序/基础设施部署的标准实践？应该：

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

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

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

会报价阿利斯特·斯科特 https://watirmelon.com/ from 2015年GTAC https://developers.google.com/google-test-automation-conference/2015/presentations#Day1Presentation5我参加过：

不要害怕向您的应用程序添加不具有功能性目的的可测试性特定功能。我最近不得不在我的车上安装新轮胎，并意识到很多轮胎都具有称为胎面指示器的可测试性功能。这些不具有功能性目的

对于集成和 e2e 测试，即需要使用超过 1 个 docker 镜像的测试，我更喜欢CI tool http://12factor.net/build-release-run那，通过docker 撰写 https://docs.docker.com/compose/以及用于这些测试的单独 git 存储库，协调创建大型测试所需的所有容器。再次使用 docker 镜像应该与生产完全相同 http://12factor.net/dev-prod-parity except 不同的是配置 http://12factor.net/config（例如环境变量）使测试指向测试数据和/或登台服务。