环境依赖。原来的自动化脚本对操作系统、安装的软件环境甚至项目路径等因素都有依赖，每个开发者从版本控制库获取代码之后还需要复杂的配置才能让系统在本地运行。

自动化不彻底。原来的自动化脚本没有覆盖到构建的所有环节，并且各个环节之间没有连通，开发者必须执行多个步骤的操作才能完成构建。

在这样的自动化脚本基础上，持续集成环境无法发挥出它最大的价值，因此我们对自动化脚本做了一系列改进，达到的效果是：只要在一台干净的机器上安装Java和Ant，然后从版本控制库签出（check out）项目，在项目目录里执行ant即可完成整个构建。于是完整的构建不仅在持续集成服务器上频繁运行，还在每个开发者的工作机器上更加频繁地运行。

在这个过程中我们用到的工具（前台部分）包括：

持续集成服务器：CruiseControl

项目自动化工具：Ant

测试覆盖率和代码复杂度统计工具：Cobertura

代码风格监测工具：Checkstyle

安全网

正如前文提到的，对于重构性质的story，测试覆盖率是一项重要的验收条件。这是由重构任务的特性决定的。

重构（名词）：对软件内部结构的一种调整，目的是在不改变“软件之可观察行为”的前提下，提高其可理解性，降低其修改成本。

重构之前，首先检查自己是否有一套可靠的测试机制。

——Martin Fowler，《重构》 

没有一套可靠的测试机制，重构就无从谈起，因为你根本就无从知道自己做的调整是否改变了“软件之可观察行为”，甚至可能已经搞得系统不能运行还一无所知。而eMAN的现状正是如此：验收测试无法自动运行，单元测试更是在上一个版本交付之后就再也没有运行过。简而言之，eMAN目前没有测试。

对这种没有测试的系统进行重构，就像是编织一张网：先针对一小块功能编写验收测试，在这张“粗网”的保护下再逐渐给代码添加单元测试，有了粗细两层网的保护再深入重构。随着重构的开展，这张频繁自动化运行的安全网也渐渐铺开。从不断提升的测试覆盖率和不断降低的代码复杂度，我们就能清晰地看到重构的进展情况。 

图3

为什么要首先编写验收测试？当然了，如果代码本身结构良好，单元（类、方法）之间关系清晰，你也可以直接添加单元测试——但这样的代码基础就不需要大动干戈地专门组织重构了。我们在eMAN项目中发现，那些最需要重构的代码也是最难进行单元测试的，而没有测试我们又不敢动手重构。（在“典型案例”一节我们将介绍几种阻碍单元测试的常见情况和解决办法。）这时验收测试就可以在系统外围担任“看门人”，给我们一个起点：在调整代码结构以便单元测试时，我们至少知道这些调整没有破坏系统的功能。

在eMAN项目中，我们用Rational Functional Tester（RFT）来做验收测试。我们还评估了另一种针对Swing应用的功能测试工具Abbot。相比之下，RFT最大的优势在于独立性：测试工具与被测应用在不同的Java虚拟机里运行；而Abbot则是在当前虚拟机环境下运行被测应用，如果被测应用与Abbot引用同样的第三方包，就可能出现版本冲突。但RFT也有一些明显的劣势：测试案例编写难度大，占用系统资源多，与Ant集成不佳，而且价格不菲。读者应该根据自己项目的情况谨慎选择。

除了用RFT实现前台Swing应用的验收测试之外，我们还用Selenium实现了前台Web应用的验收测试。对Abbot的研究也没有浪费，我们用它来实现了Swing界面的单元测试。从理论上来说，任何一段代码都可以并且应该被测试，但适当的工具能让测试事半功倍。组合多种测试工具，从不同层面、不同角度对系统进行测试，才能织起一张可靠的安全网。

与通常说的“测试驱动开发”（TDD）相比，这种重构项目的节奏略有些不同：不是标准的“红-绿-重构”，而经常是“绿-重构-绿”。不过，这两种节奏都是敏捷项目中很常见的，下面的图就同时包含了两者。

图4

值得一提的是，图中的弧线不仅代表开发中的一项活动、系统状态的一次变迁，而且还代表一次在结对中转移键盘的机会。在eMAN项目中，我们经常以这样的方式工作：一个人给现有代码补上一段测试，把键盘推给身边的同伴，后者重构被刚才的测试覆盖的那段代码。以这样的节奏稳步前进，确保了知识能够在结对的过程中得到传递。