【IT168 技术文章】

　　 一、可测试性设计

　　 1. 接口依赖

　　 这是最重要的一点，因为这可以使得我们很容易的针对一个接口实现Mock对象，模拟/替换实际对象会变的很容易。达到使一个被测对象处于一个孤立环境的测试要求。

　　 这里，ClassA依赖于ClassB的具体实现，TestCase根本无法独立于ClassB对ClassA进行独立测试。

　　 因此，我们将ClassA改为依赖于接口B_Inf。这样，可以很容易的实现一个Mock_B替换ClassB去ClassA进行孤立测试。

　　 2. 依赖注入

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

　　 3. 降低耦合度

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

　　 5．AOP

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

　　 6. 明确的契约

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

　 二、可测试性重构

　　 1. 可恶的静态方法

　　 在我们的代码中有大量的调用静态方法的地方。用起来我们很爽，但这对测试来说却是灾难。因为我们除了通过改变代码创建stub来改变这些方法的行为外，我们没有任何途径。更要命的是，写这些stub的代价非常的巨大，常常令人望而却步。

　　 解决方案：

　　 将方法内部的这些调用提取成protected方法。在外部创建待测类的子类，重写该protected方法。

　　 非常好的实践：

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

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

　　 2. 待测类方法中，new出另一个对象并使用其方法

　　 两种方案：

　　 1）将new 出对象的过程封装成protected方法。同重构1。
　　 2)将该对象提取成类属性，即由使用关系变成关联关系。

　　 3. 分离不可测/不必测代码

　　 在不影响的情况下，将不可测部分分离到一些不需要测的简单方法中去。或者将可测的部分提取到一个私有方法中去。然后针对这个私有方法进行测试。

　　 通常这种做法使用范围有限，但有些时候还是值的一试。

　　 4. 单一职责

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

　　 5. 为类提供一个空构造方法。

　　 我们的各个测试方法都依赖于对象处于一个特定的状态，满足一定的前置条件。而要将对象置为我们希望的状态，我们必须首先拥有一个对象。然而，很多时候，在一个隔离的单元测试环境下，构造函数由于各种原因不能正常初始化。

　　 此时，可以为类提供一个的空的构造方法。在外部构造一个“裸”对象，而后根据前置条件将各个属性设置成需要的Mock对象。