提高单元测试代码可测试性要点：

　　1、注释需要详尽。特别对于接口，要描述清楚功能、实现及参数；

　　2、为集成测试与系统联调准备调测开关及相应打印函数，并且要有详细的说明；

　　3、方法定义具备原子性, 一个逻辑修改应该只涉及到一个方法, 如果要改多处地方, 那么，第一时间就要反思它们是否还可以抽离成一个新方法，以唯一的支持这个逻辑的变动。

　　4、方法参数尽可能简单, 参数个数尽可能少, 特别是对于Model型对象，最好所有的参数都是简单数据类型, 原因很简单, 如果调来调去的都是一个一个笨重的对象, 那在写单元测试时，参数构造非常麻烦。

　　5、使用模块化方法，编码低耦合、高内聚。耦合性低是所有软件开发的根本原则了, 但他在代码可测试性中也是非常重要的。更低的耦合性，能够保证在测试时更容易的定位问题,而不是需要查找很多类才能定位问题。

　　6、所有的方法都应该在某个地方有输出. 从测试的角度上讲, 没有输入的方法是无效的方法,为什么说某个地方而不是自己有输出, 是因为我们都知道, 在应用中有很多方法是纯业务流方法，它改变了很多其他(模型)类的属性,而本身却不需要有任何的反映, 自己不需要或不方便提供返回值. 但是, 我们知道，恰恰是这些业务流方法，是最容易发生修改的, 那么,如何保证它们都正确执行呢? 首先,要找它影响的类, 看是否能被外部(最起码在写单元测试时)获取到, 如果能获取到并且它们的改变已经完全的反映了该方法的逻辑,那么，该方法就是可被测试的,而如果不是，就要考虑给这个方法提供必须的返回值，以反映执行完这个方法的结果。

　　7、把对第三方框架的调用和第三方接口的调用压缩在尽可能小的范围。对于方法的可测试性是必须保证方法中对第三方接口调用单独提炼出一个方法，而且保证这个方法没有任何业务逻辑，这样我们才能用mock方式mock掉接口，方便测试。

　　8、接口依赖。要很容易地针对一个接口实现Mock对象，模拟/替换实际对象会变的很容易。达到使一个被测对象处于一个孤立环境的测试要求。

　　9、依赖注入。一个方法对外部类的依赖，应该是可注入的。即可以通过构造方法、get/set方法的方式在外部将依赖关系注入。事实上，这也为我们在测试用例中替换待测类的依赖对象提供了机会。不应该出现在方法内部新建对象使用的情况。

　　10、降低耦合度。待测类应与最少的类耦合，即最小交互原则。特别是要减少与那些离了具体环境就不能运行的类的耦合。可以通过门面模式等对外部调用进行隔离。

　　11、AOP面向切面编程。给我们提供的启示是，将真正需要测的逻辑分离出来。摆脱那些无意义且简单重复的代码对测试的干扰。

　　12、明确的契约方法一定要有明确清晰的输入/输出。建议在方法的注释描述中，分三段“描述”“前置条件”“后置条件”。

　　13、非工具类不要用静态方法。将方法内部的这些调用提取成protected方法。在外部创建待测类的子类，重写该protected方法。

　　这些静态方法由单态类提供，单态类由工厂方法获取，具体类使用这些单态类的接口。

　　我们在方法中通过接口使用对外部模块的调用。一方面，隔离了外部模块改变对我们产生的冲击，另一方面，也使我们使用Mock替换实际的外部组件，创建孤立测试环境成为可能。

　　1、待测类方法中，new出另一个对象并使用其方法。两种方案：

　　1）将new 出对象的过程封装成protected方法。同重构1。

　　2)将该对象提取成类属性，即由使用关系变成关联关系。

　　2、分离不可测/不必测代码。在不影响的情况下，将不可测部分分离到一些不需要测的简单方法中去。或者将可测的部分提取到一个私有方法中去。然后针对这个私有方法进行测试。通常这种做法使用范围有限，但有些时候还是值的一试。

　　3、单一职责。职责太多，肯定不好测。针对于这一点“不好测的方法必然不好用”。当方法过大，承担责任过多时，拆分是应该的。

　　4、为类提供一个空构造方法。我们的各个测试方法都依赖于对象处于一个特定的状态，满足一定的前置条件。而要将对象置为我们希望的状态，我们必须首先拥有一个对象。然而，很多时候，在一个隔离的单元测试环境下，构造函数由于各种原因不能正常初始化。此时，可以为类提供一个的空的构造方法。在外部构造一个“裸”对象，而后根据前置条件将各个属性设置成需要的Mock对象。