图书摘录：持续集成意味着持续测试

持续集成（Continuous Integration，CI）是一个基本的极限编程（XP）实践，就算是永远不会考虑实施XP 的团队也一样在用持续集成。Martin Fowler 曾经指出过，从这一点上来看，它已经变成了任何一个出色的软件开发活动中的基础组件。Paul Duvall，Steve Matyas 和Andrew Glover 是“持续集成：改善软件质量并降低风险（Continuous Integration: Improving Software Quality and Reducing Risk ）” 一书的作者，他们希望通过这本书能够帮助开发团队把“持续集成”这项重要的开发实践变成项目中的“ non event ”，也就是自然而然的日常发生的事情。如果成功地实施了持续集成，那么就可以保证每个开发人员自己的工作和共享的项目状态之间只有几个小时之间的距离，并且可以在数分钟之内同步。InfoQ 提供了“持续集成”这本书中的“第六章：持续测试”的免费下载（pdf 版本，共 14MB），在该章节中介绍了编写不同种类测试以保证系统质量的策略。

测试是改善持续集成的关键环节，因为应用程序的构建时间大部分都是用来执行测试的。结构混乱的测试栈会导致构建陷入困境，而开发团队就不得不扔掉先前已经达成共识的持续集成实践，来换取用于编码的时间。这种所谓的捷径就又会使得“红色（表示失败）”构建频繁，进一步演化成为“门窗全毁”的场景，从而导致“红色”构建比正常构建的频率要高的多，以至于无法判断代码质量。而出现严重的产品问题的风险也会随之提高，最后开发人员就不得不进行长期的预发布测试，延长了部署时间。

在本章中，作者描述了以下种种主题及其之间的关系：

• 自动化单元测试
  将单元测试自动化，特别是可以使用 NUnit 或 JUnit 这样的单元测试框架。单元测试不应该依赖于文件系统或者是数据库这样的外界条件。
• 自动化组件测试
  使用 JUnit，NUnit 这样的单元测试框架来将组件测试自动化，如果你在使用数据库的话，还可以使用 DbUnit 或是 NDbUnit。这些测试会包括更多的对象，也通常要比单元测试花费更多的时间。
• 自动化系统测试
  系统测试比组件测试要花更长的时间运行，通常会有多个组件参与其中。
• 自动化功能测试
  我们可以通过 Selenium（用于 Web 应用程序）和 Abbot（用于 GUI 应用程序）来完成自动化功能测试。功能测试是从用户的角度来执行的，基本上算是自动化测试栈中所需时间最长的测试。
• 将开发者的测试进行分类
  把测试按照种类划分开来，就可以让速度慢的测试（比如组件测试）和速度快的测试（比如单元测试）按照不同的时间间隔来运行。
• 首先运行较快的测试
  单元测试要先于组件、系统和功能测试运行，通过按种类划分测试就可以做到这一点。
• 为缺陷编写测试
  基于新的缺陷来编写测试，保证该缺陷不会再一次为团队带来痛苦，测试代码的覆盖率也会相应提高。
• 让组件测试可重复执行
  使用数据库测试框架来保证测试数据一直处于“已知的状态下”，这可以帮助组件测试做到可重复执行。

本章以一系列的问题作为收尾，开发团队可以用这些问题来评估自己的 CI 测试过程：

你是否把自动化测试进行了分类，例如单元测试，组件测试，系统测试和功能测试？ 你是否对 CI 系统做过配置，以使它可以在不同的构建阶段来运行不同种类的测试？

你是否在为每一个缺陷编写自动化单元测试？

你的测试用例中有多少断言？你是否限制每一个测试只有一个断言？

你的测试是可以自动化运行的么？你的项目是否会把提交过的自动化测试代码放到版本控制仓库中？

在这一章里，作者还以各种测试框架中的例子进行了翔实说明，这些测试框架包括 TestNG，Ruby，DbUnit，StrutsTest，Selenium 和 JUnit 等。

敬请阅读 InfoQ 为您独家奉上的章节摘录：“第六章：持续测试”，同时您还可以在O’Reilly Safari 上看到完整的目录，从而对全书所讲述的其他主题有大致的了解。

查看英文原文： Book Excerpt: Continuous Integration means Continuous Testing