抛弃代码的坏味道 - 提升代码质量之可测试性

本文是提升代码质量第二篇：对于代码可测试性，我所遵守一些原则。
第一篇传送门 提升代码质量之可读性 https://www.jianshu.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(); }
  

反例引用静态字段，隐藏字段是否存在外部修改的可能性。

• 不要过多使用线程

  线程间数据共享不仅是软件开发面对的难题，测试也面临相同的困境。

• 不可变对象（变量和类）是头等公民

  不解释

• 保证独立性

  独立性表现在减少外部依赖，又要减少功能的依赖。可测试性困局根本原因是没有意识到独立性重要性。

• 减少频繁重构

代码可读性是不断迭代出来的，而重构对代码可测性维护带来额外的负担。我们要修改已有的测试代码，又要新加新的功能测试。因此，重构代码提升质量，也要承担额外的工作。权衡重估必要性。

我家等哥说：爸爸又在码字不陪我玩了，给他点个赞哈。