[ 行业动态 ] 第8期 2009年8月
持续测试时代来临
作者 Andrew Binstock，他是硅谷太平洋数据工程有限公司的首席分析师，同时也是 InfoWorld 杂志的资深编辑，是软件开发工具和工程设备的评论专家。
敏捷活动的核心特点是“经常发布”。很多小的发布其目的是给开发者尽早的，经常性地提供反馈。为使得项目完全符合需求尤其是用户和客户需求，它允许用户做变更。事实证明，经常发布是一种能够用来改善产品的手段，敏捷从业人员意识到它对开发团队成员来说也一样。也就是说，如果开发者很快完成了编码并且立刻开始非编码活动，他们能够就刚才所做的事情得到最及时的反馈。
单元测试就是一个用来提供反馈的绝好工具。比如说：你编码，测试，找出破绽，并且决定如何对付测试的反馈信息。你可能突然发现如果你天真地继续顺着某条思路走，你将因为错失了关键问题而越走越远。你小心地备份（通过测试反馈，你能知道需要备份多少东西），并且发现了一条不同的能够解决刚才标注的系列问题的方法，这一切都充分地利用了测试。另外的相似例子都表明在你编码后，越早进行测试，那么你就能越早的解决问题并且做必要的调整。
越早的对测试过的代码进行回归测试，就越容易解决问题，我们要尽早地把问题分散。就像我之前的文章讨论过的，持续集成软件能够监控源代码库，并且每次代码做 check in 的时候都会建立一个新项目。这使得开发者在最短的时间里知道哪些需要重建。一个项目可能整天都在做却没有每天 build，甚至好几天都没有。因此当 build broke 的时候，大家想起来做的只是有限的拖延交付时间。但是如果能够找到几小时前代码 check in 记录的话，开发者将能快速的找到错误代码并修复。
一个叫做持续测试的新趋势出现了，当开发者编码的时候在 IDE 中运行单元测试。不同的产品，它有着各自的方法用来做测试。有些产品，能够依据开发者自己的需求及偏好，用红/绿条不同的颜色在 IDE 里进行区分。这种思想再一次用来测试新的代码，进行单元测试或者特性测试，用来跟踪范围的变更。通过经常性地运行测试，大大缩短了反馈环节，开发者能够更好的顺着思路去做决策。依据 David Saff 对 MIT 的研究发现，坚持用持续测试的开发者总是能按时交付，即使出现了变更。因此，我认为这一切都是因为他们从来没有对意想不到的变更采取视而不见的态度。
连续测试还有其它的优势：如果采用传统的非 TDD（Test Driven Development） 模式，开始是写代码，然后测试，有代码更改的话则再次测试。那么在大型项目里，运行测试需要一段时间，这意味着运行测试的时候，开发者将分心去做其它的事情，比如说处理 Email，回复即时短消息等。如果测试信息能及时反馈，就不会这样。而且，持续测试屏弃了传统的在测试前写海量代码的行为。
如今，有在 Java 两种重要的持续测试产品，分别是 Ben Rady 的 Infinitest 和 Kent Beck 的 JUnitMax。两者都可以用来做为 Eclipse 的插件，并且Infinitest 可以用做其它的 IDE，对于 Ruby 语言写的程序，ZenTest 是唯一目前我知道的工具。