1.5　使用增量方法

　　与很多团队一样，我们发现在每两周的迭代后期都有未完成的测试任务。有时候用户故事未完成。比如，我们从一个包含5页向导程序的UI开始一个故事（story），其中只有4页完成了。

　　有一位程序员提议用一个“强线程”（steel thread）来标识复杂故事——一个将功能点从不同终端隔离开来的小的功能点。我们为它编写测试、写出代码，然后将测试自动化然后转移到下一个线程。那样的话，测试自动化即便在GUI层面，也能与开发保持一致。第一个自动化的测试可能会过于简单，但可以逐步进行补充。

　　【小窍门】

　　强线程是一种保证自动化在时间里程碑内完成的方法。

　　这种方法很有效，对于每一个计划的复合功能点，我们首先将线程画在白板上，并确保在转移到下个线程之前，当前线程的自动化测试及手动测试都已经完成了。

　　1.6　正确度量

　　如何知道我们是否取得进步了呢？如何衡量成功？我们需要一些度量。我们的构建过程会对测试进行统计，所以很容易跟踪每一个层次的测试数量：JUnit、FitNesse断言和测试页面、Cannoo WebTest断言等。

　　这些原始数据并不能代表整个趋势。我们，包括业务经理，都希望看到这些数字在每次迭代中都在增长。在每一次迭代中，指定一份染色的日历——如果某天所有的回归测试至少通过了一次，则将其日期标记为绿色，否则标记为红色。业务人员也非常关注这些数据，如果他们在一行里面看到两个标记为红色的日期，他们会向我们询问原因。他们也会记录每一次迭代中JUnit、FitNesse和Canoo WebTest的测试数量。当测试数量减少时，他们也会关注并询问原因。

　　【真知灼见】

　　让经理看到自动化测试的好处。你需要不断“推销”自动化的好处。

　　让测试结果对外可见也是一种宣传的形式，可在整个公司范围内加强公众对自动化回归测试的了解。客户看到测试数量增加，并且发布的功能点越来越多。所以，当我们申请时间来重构产品或者改善构建过程时，我们的客户就能够理解了。

　　我们需要快速的反馈，所以每一次构建花费的时间是一种重要的度量。如果运行JUnit测试的持续构建花费的时间超过10分钟，就开始备份检入信息，那么就很难找出是哪一个测试导致了失效。当JUnit构建花费的时间超过10分钟时，我们停下来查看是什么原因导致了运行缓慢。我们重构测试、添加硬件、升级操作系统、配置测试使其并发运行等，这些都会使反馈循环更快。对运行更高级测试的构建也是这么做的。如果FitNesse测试要花好几个小时来运行，那么反馈太慢。我们要在测试覆盖和速度之间权衡。幸运的是，虚拟机可以同时运行多个测试套件，减少反馈周期并且非常廉价。

　　【小窍门】

　　不要使自动化停滞不前：在需要的时候进行重构、使用新的硬件、重组测试。记住我们的目标（这里指更快速的反馈），并修改自动化测试来达到我们的目标。

　　1.7　庆祝成功

　　100个JUnit测试并不是很多，但每一个测试代表了许多断言，并且是一个值得庆祝的里程碑。当达到1000个JUnit测试时，我们觉得这值得全公司聚会庆祝一下，并为全公司的人购买了比萨。当庆祝第2000个JUnit测试时，我们组织了一个有饮料和拼盘的小型聚餐。有人曾经问过我，这些庆祝会不会鼓励一种不好的事情：盲目增加不必要的测试数量。其实，因为每个测试都是刚好在让其通过的那部分代码之前编写的，所以我们没有进行任何无关的单元测试。如果包含测试的代码移除了，那么测试也会移除。

　　当接近3000个JUint测试时，敏捷教练让我撰写一份说明书，谈谈在单元测试级别中一个健壮的回归测试套件对业务的重要意义。我写了一份关于TDD的高级描述报告，即它是如何帮助我们开发出健壮的、易维护的代码，并在单元测试级别为我们提供了回归测试覆盖的安全网。我试图阐明JUnit的目的：帮助设计代码。也就是说，我们不是胡乱编写单元测试的。敏捷教练把这份报告发给公司的每个人，并在一家本地饭店预订了一个聚会。不仅是为了庆祝我们完成任务，而且让所有的业务利益相关者也能体会其中的意义。