不要再偷懒，请测试你的软件（借力 Docker）

在 DockerCon EU 2015 大会上， Laura Frank 作了题为“不要再偷懒，请测试你的软件”的演讲。Frank 指出，不管公司规模大小，也不管公司处于什么阶段，软件测试都至关重要，而将 Docker 引入开发流程有助于提高编写和运行测试框架的效率，使组织能够始终如一地向客户提供高质量的软件产品。

Frank 是一名来自 Codeship 的资深软件工程师。他在演讲开始时说，软件测试自首台用于计算的机器出现时就已经开始了。有位女士为第一台通用电子计算机 ENIAC 编写了程序，用于帮助美国陆军弹道研究实验室计算炮兵射击轨迹。她会定期拿一份已知正确的、手工计算的表格检查计算结果。Frank 指出，与其他技术（如结对编程、版本控制、代码审查和高可用架构）一样，测试对交付“可用于生产环境的软件”而言至关重要。

测试的目的包括升级应用程序并避免引入回归缺陷，验证更新的功能，证明重构没有破坏现有的功能。编写测试和测试套件本地运行耗时过长，正常开发流程受到干扰，测试环境难以正确配置，这些往往会让人沮丧。Frank 提出，将 Linux 容器和 Docker 工具箱引入测试创建和执行过程可以部分地缓解这种沮丧。

Docker Compose 使用户很容易就可以创建一致的、可重现的容器化环境。Frank 表示，许多软件开发人员都使用 Docker Compose 创建本地开发环境，但却没有将其用于软件测试。在测试中使用 Docker 同在开发中使用 Docker 有同样的好处，如创建可预测、可重现的环境，这对质量保证过程非常有益。

Docker 可以提供可预测且可重现的测试环境。就是这样。

Frank 提醒说，在将 Docker Compose 用于测试时，可能需要对其工作流做一些修改，甚至需要使用一个不同的 Dockerfile 指定不同的环境变量和运行目标，Docker Compose 通过“ docerfile ”属性提供这种支持。当容器、应用程序和存储配置复杂时，要注意避免初始化和执行竞态条件。

Docker Compose 的 docker-compose up 命令可以用于执行一个编入 Compose YAML 配置文件的自动化测试套件，也可以使用 Compose 的 run 命令一次运行一个服务，比如：

 
$ docker-compose up
$ docker-compose run -e “RAILS_ENV=test” app rake db:setup
$ docker-compose run -e “RAILS_ENV=test” app test-command path/to/spec.rb

Frank 提到，持续集成与测试相辅相成，依赖 CI/CD 而测试覆盖率不足通常会出问题——与在生产环境中发现缺陷相比，开发人员更愿意看到持续交付管道运行失败。

需要注意的是，运行测试的环境与生产环境差别越小越好。Frank 认为， 如果应用程序将来会运行在容器中（并且在容器中开发），那么构建管道中的测试也就必须在容器中进行。为此，开发人员可能会倾向于运行“Docker-in-Docker”。Frank 指出，任何考虑这样做的人都应该读下 Jérôme Petazzoni 的著作，比如文章“将Docker-in-Docker 用于CI 或测试环境？请三思而行”。

Frank 认为，在开发过程中使用容器时，很容易错误地将容器看作一个运行特定负载的“小型虚拟机”。然而，如果能更准确地将容器视为简单 OS 进程，那么测试过程就可以获得额外的好处。例如，需要在容器化应用程序上运行的多个测试可以并发执行。在 DockerCon 欧洲大会质量改进主题的基础上，Frank 提出，可以增加一个并发构建管道，当质量下降时（比如测试代码覆盖率降到一定水平之下， linting 错误增加，或者违反 ratchets 中的规则），使构建失败，以此保证软件的质量。

Frank 引用 Edsger Dijkstra 的话对演讲进行了总结。他表示，虽然测试至关重要，但它并不能保证开发出的软件没有缺陷，应该恰当设定测试预期。

测试是一种显示 Bug 存在的有效方法，但却不足以显示它们不存在。

读者可以从 SlideShare 上下载 Frank 演讲用的幻灯片，演讲视频稍后将在 Docker YouTube 上提供。

查看英文原文: Stop Being Lazy, and Test Your Software (with the Help of Docker)