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

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

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

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

Docker Compose 使用户很容易就可以创建一致的、可重现的容器化环境。Frank表示，许多软件开发人员都使用Docker Compose创建本地开发环境，但却没有将其用于软件测试。在测试中使用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 的话对演讲进行了总结。他表示，虽然测试至关重要，但它并不能保证开发出的软件没有缺陷，应该恰当设定测试预期。

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

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