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

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

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

  • 不要过多使用线程

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

  • 不可变对象(变量和类)是头等公民

    不解释

  • 保证独立性

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

  • 减少频繁重构

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

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

推荐阅读更多精彩内容