本文是提升代码质量第二篇：对于代码可测试性，我所遵守一些原则。
第一篇传送门 提升代码质量之可读性 //www.greatytc.com/p/38ee35af9f67
爱因斯坦如是说： Only two things are infinite - the universe and human stupidity, and I'm not so sure about the universe. -- Albert Einstein
为了规避这种无底线的错误，各个行业做了多种尝试。在软件开发领域测试是我们为此做的努力。 而在不同领域软件测试分类不尽相同。
我们一直说：没有不可测试的功能，只有不可测试的代码。代码质量决定测试成本，和为保证软件质量要耗费的努力。
粗略来分是：单元测试和系统测试。
而单元测试如同金字塔的根基，它好坏直接决定软件质量和研发效率。
本文内容针对单元测试。
如何让代码具备良好可测试性哪？不是用例难写，而是代码不可测试让用例难写。下文列出一些原则与你共飨。
代码可读性和可测试存在重复环节，也有不少不同。文中内容只是个人经验总结和习惯，希望对你有益。
使用好的框架， 统一描述语言
每个语言都有一些测试框架，提供了语法糖和特性，拿来即用。测试框架就像语言，让我们用统一的语言沟通，测试用例也会规范化。如Java的mockito、JUnit、JTest等。持续性测试
把用例当作开发的一部分，而不只是为了满足覆盖率等形式化。实践标明：用例覆盖软件代码，可持续进行改进软件质量，对程序维护和新功能开发大有裨益。合理使用设计模式
设计模式点亮世界。滥用模式让软件重新走进黑暗。不能因为模式而模式，设计要适可而止。减少链式调用
object.message(); // 正常调用
object.someOtherObject.someService.getMeSomeInfo(); // 多级调用 **反例**
反例中代码容易理解，可读性较高。但可测试性上，却大打折扣。每一级调用是否幂等都存在未知数。非系统函数调用禁止这样编写代码。从这点上看，代码可读性和可测试性不完全统一。即可读性并不意味着易于测试。
- 隐藏依赖
减少外部依赖，尤其依赖外部库时，我们要进行依赖隔离。
string GetTimeOfDay()
{
DateTime time = DateTime.Now; // ** 引入依赖 **
if (time.Hour >= 0 && time.Hour < 6)
{
return "Night";
}
if (time.Hour >= 6 && time.Hour < 12)
{
return "Morning";
}
....
return "Evening";
}
函数GetTimeOfDay功能单一，可读性很强。但是结果依赖 DateTime.Now;，调用函数结果无法确定，很难编写稳定的单元测试，可测试性很差。修改方法如下：
string GetTimeOfDay(DateTime time)
{
//隐藏依赖，作为参数进行传递
// DateTime time = DateTime.Now;
....
}
老代码可读性不错，但在可测试性上存在瑕疵。这也是之前提到的：代码可读性和可测试性存在部分交叠情况。
-
避免静态属性和字段调用
if (Mode.isDefaultMode) { gpPoolController.Connection(); }
反例引用静态字段，隐藏字段是否存在外部修改的可能性。
-
不要过多使用线程
线程间数据共享不仅是软件开发面对的难题，测试也面临相同的困境。
-
不可变对象（变量和类）是头等公民
不解释
-
保证独立性
独立性表现在减少外部依赖，又要减少功能的依赖。可测试性困局根本原因是没有意识到独立性重要性。
减少频繁重构
代码可读性是不断迭代出来的，而重构对代码可测性维护带来额外的负担。我们要修改已有的测试代码，又要新加新的功能测试。因此，重构代码提升质量，也要承担额外的工作。权衡重估必要性。
