二、可测试性重构
1. 可恶的静态方法
在我们的代码中有大量的调用静态方法的地方。用起来我们很爽，但这对测试来说却是灾难。因为我们除了通过改变代码创建stub来改变这些方法的行为外，我们没有任何途径。更要命的是，写这些stub的代价非常的巨大，常常令人望而却步。
解决方案：
将方法内部的这些调用提取成protected方法。在外部创建待测类的子类，重写该protected方法。
最佳实践：
我们在方法中通过接口使用对外部模块的调用。一方面，隔离了外部模块改变对我们产生的冲击，另一方面，也使我们使用Mock替换实际的外部组件，创建孤立测试环境成为可能。
2. 待测类方法中，new出另一个对象并使用其方法
两种方案：
1）将new 出对象的过程封装成protected方法。同重构1。2)将该对象提取成类属性，即由使用关系变成关联关系。
3. 分离不可测/不必测代码
在不影响的情况下，将不可测部分分离到一些不需要测的简单方法中去。或者将可测的部分提取到一个私有方法中去。然后针对这个私有方法进行测试。
通常这种做法使用范围有限，但有些时候还是值的一试。
4. 单一职责
职责太多，肯定不好测。针对于这一点“不好测的方法必然不好用”。当方法过大，承担责任过多时，拆分是应该的。
5. 为类提供一个空构造方法。
我们的各个测试方法都依赖于对象处于一个特定的状态，满足一定的前置条件。而要将对象置为我们希望的状态，我们必须首先拥有一个对象。然而，很多时候，在一个隔离的单元测试环境下，构造函数由于各种原因不能正常初始化。
此时，可以为类提供一个的空的构造方法。在外部构造一个“裸”对象，而后根据前置条件将各个属性设置成需要的Mock对象。
相关文章：
