在这些条件下，伪造一个RGHConnection对象最好的方法是对RGHConnection类应用接口提取。如果你手头一个支持重构的工具，那么它很可能也会支持接口提取方法。我们来看一下接口提取后的情况：

　　由于retry()和fromPacket()不属于业务相关方法因此只需要在实现类中增加这两个方法，至此我们可以轻松的构建出一个FackeConnection类，并使它能够提供我们所需要的反馈信息，然后将这个伪造的对象用在测试中：

　　下面我们来写测试

　　虽然FakeConnection类看起来有点奇怪：它的方法要么是空的要么就简单的返回null。这种情形并不常见。更糟的是，它有一个任何人都可以看到的并随意设置的公共变量。这样一个类似似乎违反了所有的良好准则。但你要看到，实际上并非如此。对于一个用来使得测试可行的类，规则是所不同的。FakeConnection中的代码并非产品代码。它永远也不属于最终投入运行的应用，而只是为了测试工具和测试而诞生。

　　有了这个fake类我们接下去便可以做更多的相关测试。这就是提高代码可测试性和遇到教难构造的的类的时候所采取的一种方法。若代码设计阶段就将RGHConnection设计为接口，那么在后面的测试中会是测试更加方便，使代码在后期的重构也会更加方便。

本文是在读了《Working Effectively with legacy Code 》第九章，关于在无法将类放入测试用具中时遇到的四种最为常见的问题：

　　（1）无法轻易创建该类的对象。

　　（2）当该类位于测试用具中时，测试用具无法轻易通过编译构建。

　　（3）我们需要用到的构造函数具有副作用。

　　（4）构造函数中有一些要紧的工作，我们需要感知到它们。

　　这四个问题在进行单元测试或者接口测试的时候，会对测试工作造成很大的阻碍，这就是一个代码可测性的问题。当遇到这样的问题的时候，有两种方法，第一、强行构建一个类去完成测试，但是这会造成测试的时候大部分工作都耗费在构建这样一个类的过程中；第二、重构代码，使代码具有可测性。本文将通过书中的列子来简单介绍一下如何提高代码的可测性。

　　如在一个计费系统中，我们有一个未测试的Java类：CreditValidator。

　　我们可以看到CreditValidator构造函数含有三个参数RGHConnection，CreditMaster，validatorID。其中RGHConnection对象在构造时会连接到一个服务器，这个链接被用来从服务器上获取必要的信息，以检查客户的余额。

　　宁一个类CreditMaster，则提供一些我们在检查余额的过程中会用到的策略信息。该类的构造函数会从一个文件中加载相关信息，并把这些信息保存在内存中以备后用。

　　如果按照我们开头讲的强制构造一个类来完成测试，如下所示：

　　虽然我们构建一个这个样的类，但是你能忍受这个测试的速度，根据《Working Effectively with legacy Code 》书中提到大于1秒的单元测试，都不叫单元测试。因此在测试中建立到服务器的连接并不是一个好的主意。首先其好事就比较长，况且服务器也并不总是处于服务状态。可想而知RGHConnection是一个令人恼火的参数。我们的设想是：若能创建某种伪造的RGHConnection对象并使CreditValidator相信它是一个真正的RGHConnection的话，就可以避开所有链接的问题了。

　　首先来看一下RGHConnection所拥有的方法：

　　看上去RGHConnection中有一些方法是用来处理与连接相关的任务的：如connect、disconnect以及retry。另外还有一些业务方法。因此如果要伪造一个RGHConnection对象的话，那么这个伪造的对象也必须拥有这些方法也能提供一样的信息。

====================================分割线================================

最新内容请见作者的GitHub页：http://qaseven.github.io/