安全网

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

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

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

    ——Martin Fowler，《重构》

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

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

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