Mock 不是测试的银弹

开发者编写高质量测试的征途上可谓布满荆棘，数据库、中间件、不同的文件系统等复杂外部系统的存在，令开发者在编写、运行测试时觉得苦恼异常。由于外部系 统常常运行在不同机器上或者本地单独的进程中，开发者很难在测试中操作和控制它们。外部系统以及网络连接的不稳定性（外部系统停止响应或者网络连接超 时），将有可能导致测试运行过程随机失败。另外，外部系统缓慢的响应速度（HTTP 访问、启动服务、创建删除文件等），还可能会造成测试运行时间过长、成 本过高。种种问题使开发者不断寻找一种更廉价的方式来进行测试， mock 便是开发人员解决上述问题时祭出的法宝。 mock 对象运行在本地完全可控环境内，利用 mock 对象模拟被依赖的资源，使开发者可以轻易的创建一个稳定的测试环境。mock 对象本地创建，本地运行的特性更是加快测试的不二法门。

我所在团队设计开发的产品是持续集成服务器，产品特性决定了它需要在各个平台（Windows, Mac, Linux 等）与各种版本管理工具 (svn, mercurial,git 等)、构建工具 (ant, nant, rake 等) 进行集成，对于外部系统的严重依赖让我们在编写测试时遇到了很多困难，我们自然而然的选用了 JMock 作为测试框架，利用它来隔离外部系统对 于测试的影响，的的确确在使用 JMock 框架后测试编写起来更容易，运行速度更快，也更稳定，然而出乎意料的是产品质量并没有如我们所预期的随着不断添加 的测试而变得愈加健壮，虽然产品代码的单元测试覆盖率超过了 80%，然而在发布前进行全面测试时，常常发现严重的功能缺陷而不得不一轮轮的修复缺陷、回归 测试。为什么编写了大量的测试还会频繁出现这些问题呢？ 在讨论之前先来看一个真实的例子：

我们的产品需要与 Perforce(一种版本管理工具) 进行集成，检测某段时间内 Perforce 服务器上是否存在更新，如果有，将更新解析为 Modification 对象。将这个需求反应在代码中，便是首先通过 Perforce 对象检测服务器更新，然后将标准输出 (stdout) 进行解析：

 
 public class PerforceMaterial {
    private Perforce perforce;
    .....
    .....
    public List<modification> findModifications(Date start, Date end) {<br></br>        String changes = perforce.changes(start, end);    // 检测更新，返回命令行标准输出（stdout）        <br></br>        List<modification> modifications = parseChanges(changes);// 将标准输出解析为 Modification<br></br>        return modifications;<br></br>    }<p>    private List<modification> parseChanges(String output) {<br></br>         // 通过正则表达式将 stdout 解析为 Modification 对象 <br></br>    }<br></br>}<p>public class Perforce {</p><br></br>    public String changes(Date start, Date end) {<br></br>          // 通过命令行检测更新，将命令行标准输出（stdout）返回 <br></br>    }<br></br>}             </modification></p></modification></modification>

相应的 mock 测试也非常容易理解：

     .....
    .....  
    @Test
    public void shouldCreateModifiationWhenChangesAreFound() {
        final String stdout = "Chang 4 on 2008/09/01 by p4user@Dev01 'Added build.xml'"; // 设置标准输出样本
        final Date start = new Date();
        final Date end = new Date();
 
        context.checking(new Expectations() {{
            one(perforce).changes(start, end);
            will(returnValue(stdout));
        }});// 设置 perforce 对象的行为，令其返回设定好的 stdout
 
        List<modification> list = perforceMaterial.findModifications(start, end);// 调用被测方法 <p>        assertThat(list.get(0).revision(), is("4"));</p><br></br>        assertThat(list.get(0).user(), is("p4user@Dev01"));<br></br>        assertThat(list.get(0).modifiedTime(), is("2008/09/01"));<br></br>    }  </modification>

测试中的 stdout 是在真实环境下运行 Perforce 命令行所采集的标准输出 (stdout) 样本， 通过 mock perforce 对象，我们可以轻易的控制 changes 方法的返回值，让验证解析逻辑的正确性变得非常容易，采用 mock 技术使开发者无需顾忌 Perforce 服务器的存在与否，而且可以采用不同的 stdout 来覆盖不同的情况。然而危机就在这看似完美的测试过程中被埋下了，事实上 Perforce stdout 中的时间格式会依用户环境的设定而变化，从而进一步导致 parseChanges 方法中的解析逻辑出现异常。由于测试中的 stdout 全由假 设得来，并不会依照环境变化，即便我们将测试跑在多种不同的环境中也没能发现问题，最终在产品环境才由客户发现并报告了这个缺陷。

真实 perforce 对象的行为与测试所使用的 mock 对象行为不一致是出现上述问题的根本原因，被模拟对象的行为与真实对象的行为必须完全一致称之为mock 对象的行为依赖风险。 开发者对 API 的了解不够、被模拟对象的行为发生变化（重构、添加新功能等修改等都可能引起被被模拟对象的行为变化）都可能导致错误假设（与真实对象行为 不一致），错误假设会悄无声息的引入缺陷并留下非法测试。非法测试在这里所代表的含义是，它看起来很像测试，它运行起来很像测试，它几乎没有价值，它几乎 不会失败。在开发中，规避行为依赖风险最常见的方法是编写功能测试，由于在进行 mock 测试时，开发者在层与层之间不断做出假设，而端到端的功能测试由于 贯穿了所有层，可以验证开发者是否做出了正确的假设，然而由于功能测试编写复杂、运行速度慢、维护难度高，大部分产品的功能测试都非常有限。那些通过 mock 测试的逻辑，便如埋下的一颗颗定时炸弹，如何能叫人安心的发布产品呢？

《UNIX 编程艺术》中有一句话“先求运行，再求正确，最后求快”，正确运行的测试是高质量、可以快速运行测试的基础，离开了正确性，速度和隔离性都是无 根之木，无源之水。那么采用真实环境就意味着必须承受脆弱而缓慢的测试么？经历了一段时间的摸索，这个问题的答案渐渐清晰起来了，真实环境的测试之所以痛 苦，很大程度上是由于我们在多进程、多线程的环境下对编写测试没有经验，不了解如何合理的使用资源（所谓的资源可能是文件、数据库中的记录、也可能是一个 新的进程等），对于我们，mock 测试作为“银弹”的作用更多的体现在通过屏蔽运行在单独进程或者线程中的资源，将测试简化为对大脑友好的单线程运行环境。在修复过足够多的脆弱测试后，我们发现了编写健壮测试的秘密：

要设计合理的等待策略来保守的使用外部系统。很多情况下，外部系统处于某种特定的状态是测试得以通过的条件，譬如 HTTP 服务必须启动完 毕，某个文件必须存在等。在编写测试时，开发者常常对外部系统的估计过于乐观，认为外部系统可以迅速处于就绪状态，而运行时由于机器和环境的差异，结果往 往不如开发者所愿，为了确保测试的稳定性，一定要设计合理的等待策略保证外部系统处于所需状态，之所以使用"等待策略"这个词，是因为最常见”保证外部系 统处于所需状态“的方法是万恶的"Thread.sleep", 当测试运行在运算速度 / 网络连接速度差异较大的机器上时，它会引起随机失败。而比较合理的方法是利用轮询的方式查看外部系统是否处于所需状态（譬如某个文 件存在、端口打开等），只有当状态满足时，才运行测试或者进行 Assertion，为了避免进入无限等待的状态，还应该设计合理的 timeout 策略，帮 助确定测试失败的原因。

要正确的创建和销毁资源漠视测试环境的清理也常常是产生脆弱测试的原因，它主要表现在测试之间互相影响，测试只有按照某种顺序运行时才会成功 / 失败，这种问题一旦出现会变的非常棘手，开发者必须逐一对有嫌疑的测试运行并分析。因此，有必要在开始时就处理好资源的创建和销毁，使用资源时应当本着这样一个原则：谁创建，谁销毁。 junit 在环境清理方面所提供的支持有它的局限性，下面的代码是使用资源最普遍的方式：

 
 @After
public void teardown() {
   // 销毁资源 A
   // 销毁资源 B
}
 
@Test
public void test1() {
   // 创建资源 A
}
 
@Test
public void test2() {
   // 创建资源 B
}

为了确保资源 A 与资源 B 被正确销毁，开发者必须将销毁资源的逻辑写在 teardown 方法中，然而运行用例 test1 时，资源 B 并未被创建，所以必须在 teardown 中同时处理资源 A 或 B 没有被创建的情况，由于需要销毁的资源是用例中所使用资源的并集，teardown 方法会快速得膨胀。由于这样的原 因，我在开源项目 junit-ext 中加入了对 Precondition 的支持，在测试用例运行前，其利用标注所声明的多个 Precondition 的 setup 方法会被逐一调用来创建资源，而测试结束时则调用 teardown 方法销毁资源。

 
 @Preconditions({ResourceIsCreated.class, ServiceIsStarted.class})
@Test
public void test1() {
      // 在测试中使用资源
}
 
public class ResourceIsCreated implements Precondition {
    public void setup() {
           // 创建资源
    }
    public void teardown() {
           // 回收资源
    }
}
 
public class ServiceIsStarted implements Precondition {
     public void setup() {
           // 创建资源
     }
     public void teardown() {
           // 回收资源
     }
}
 
public interface Precondition {
     void setup();
 
     void teardown();
}

这个框架可以更好的规范资源的创建和销毁的过程，减少因为测试环境可能引起的随机失败，当然这个框架也有其局限性，在 ResourceIsCreated 和 ServiceIsStarted 之间共享状态会比较复杂，在我们的产品中，Precondition 大多用于启动新进程，对于共享状态的要求比较低， 这样一套机制就非常适合。每个项目都有其特殊性，面对的困难和解决方案也不尽相同，但在使用资源时如果能遵守“谁创建，谁销毁”的原则，将会大大减小测试 之间的依赖性，减少脆弱的测试。

要设计合理的过滤策略来忽略某些测试。我们很容易在项目中发现只能在特定环境下通过的测试，这个特定环境可能是特定的操作系统，也可能是特 定的浏览器等，之所以会产生这些测试通常是开发者需要在源码中进行一些特定环境的 hack，它们并不适合在所有环境下运行，也无法在所有环境中稳定的通 过，因此应该设计一套机制可以有选择的运行这些测试，junit 的 assumeThat 的机制让我再次有点失望，本着自己动手丰衣足食的原则，在 junit-ext 我添加了利用标注来过滤测试的机制，标注了 RunIf 的测试仅当条件满足时才会运行，除了内置一些 Checker，开发者也可以很方便的开发自己的 Checker 来适应项目的需要。

 
 @RunWith(JunitExtRunner.class)
 public class Tests {
    @Test
    @RunIf(PlatformIsWindows.class) //test1 仅运行在 Windows 环境下
    public void test1() {
    }
}
 
public class PlatformIsWindows implements Checker {
    public boolean satisfy() {
        // 检测是否 WINDOWS 平台
    }
}

要充分利用计算资源而不是人力资源来加快测试。对于加快测试，最普遍也最脆弱的方法是利用多线程来同时运行多个测试，这个方法之所以脆弱， 是因为它会让编写测试 / 分析失败测试变的异常复杂，开发者必须考虑到当前线程在使用资源时，可能有另一个线程正要销毁同一个资源，而测试失败时，也会由于 线程的不确定性，导致问题难于重现而增加了解决问题的成本。我认为一个更好的实践是在多台机器上并发运行测试，每台机器只需要运行 (总测试数 / 机器数) 个 测试，这样所花费时间会近似减少为 (原本测试时间 / 机器数）。相对与购置机器的一次性投入，手工优化的不断投入成本更高，而且很多公司都会有闲置的计算资 源，利用旧机器或者在多核的机器上安装虚拟机的方式，可以很经济的增加计算资源。在项目开发的业余时间，我和我的同事们一起开发了开源的测试辅助工具 test-load-balancer 。在我们的项目中，通过它将需要 90 分钟的测试自动划分为数个 10 分钟左右的测试在多台虚拟机上并发运行，很好的解决了速度问题。

对 mock 追本溯源，我们会发现它更多扮演的是设计工具的角色而不是测试工具的角色，mock 框架在设计方面的局限性李晓在《不要把Mock 当作你的设计利器》一文中已经谈的很透彻，在此不再赘述。Mock 不是测试的银弹，世上也并无银弹存在，测试实践能否正常开展的决定性因素是团队成员对测试流程，测试方法的不断改进而不是先进的测试框架。不要去依赖mock 框架，它的强制约定常常是你改进设计和添加功能的绊脚石，改善设计，依赖一个简洁的代码环境，依赖一套可靠的测试方法才是正途。从意识到mock 测试带来的负面影响，到从滥用mock 的泥潭中挣扎出来，我们花费了很多时间和经历，希望这些经验可以对同行们能有所借鉴，有所启发。

Mock，还请慎用。

写在最后

在 ThoughtWorks 工作的三年经历中，对于 mock 框架的使用从无到有，到滥用到谨慎。三年间，和李晓、陶文，李彦辉，Chris Stevenson 等人反复讨论和辩论使我对mock 有了更多的理解。这篇文章反反复复改了许多稿，在此对陈金洲和李默的耐心帮助致谢。最后，没有与InfoQ 的编辑李剑和霍太稳在Twitter 上的一番谈话，也就没有这篇文章。

参考

Mock Roles, not Objects , Steve Freeman, Nat Pryce, Tim Mackinnon, Joe Walnes

不要把Mock 当作你的设计利器，李晓

作者简介：

胡凯， ThoughtWorks 公司的敏捷咨询师，近 2 年一直从事持续集成工具 Cruise 以及 CruiseControl 的设计开发工作。 创造和参与了开源测试框架 junit-ext 和 test-load-balancer ，对于 Web 开发，敏捷实践，开源软件与社区活动有浓厚的兴趣，可以访问他的个人博客进行更多的了解。

相关阅读

[ ThoughtWorks 实践集锦（1）] 我和敏捷团队的五个约定。

[ ThoughtWorks 实践集锦（2）] 如何在敏捷开发中做好数据迁移。

[ ThoughtWorks 实践集锦（3）] RichClient/RIA 原则与实践（上）、（下）。

[ ThoughtWorks 实践集锦（4）] 为什么我们要放弃Subversion 。

[ ThoughtWorks 实践集锦（5）] “持续集成”也需要重构。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。