本节是单元测试的第三篇。我以为这是重中之重的一章。单元测试的关键在于代码要可测。可测才能测。要做好单元测试，就必须在代码的可测性方面努力，在设计、重构方面用心。本篇主要分享我在如何写出可测性代码方面的理解，与大家共勉！

单元测试(提升篇)

------编写可测试性代码

一、可测试性设计

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对象。

-----------------------------------------------------------------------------------------------------------------------------------------------------------

事实上，要想写出具有可测性的代码，最佳的办法就是测试驱动开发。先写测试代码把功能体现出来，再写功能代码让测试通过。这样写出的代码显而易见会更具有测试性。