优秀的软件离不开单元测试
为什么业界都把单元测试放在这么重要的位置？“抓⼤放⼩”，只写端到端测试不⾹吗？这⾥我们来展开讲讲单测的好处。
提升debug效率
单元测试是软件⼯程极佳的地基，因为它们快速、稳定，并且极⼤地缩⼩了问题范围，提升故障诊断的效率。
●
测试更快：单测没有其他外部依赖，跑的快，可以提供更快的反馈环，更快的发现并修复问题。
●
测试更稳定：同样因为0依赖，单测相⽐于其他类型的测试更稳定，不会受外部其他模块的不兼容变更影响。因此单测也是最能带给开发者信⼼的测试类型。
●
问题更容易定位：单测以最⼩软件单位为边界，出了问题可以缩⼩定位范围。相⽐之下，越是⾦字塔上层的测试类型，定位问题的困难度越⼤。复杂的端到端测试涉及众多的模块，需要⼀⼀排查定位问题。
提升代码质量
代码是写给⼈看的，好的代码应该是易读、易改、易维护的。写单测的过程其实就是吃⾃⼰代码狗粮（dogfood）的过程，从⽤户/研发视⻆去使⽤⾃⼰的代码，帮助我们提升代码质量。
●
好的代码是易测的：业界很早就提出了圈复杂度（Cyclomatic complexity）的概念，⽤来衡量⼀个模块判定结构的复杂程度，其数量上表现为独⽴路径的条数，也可理解为覆盖所有的可能情况最少使⽤的测试⽤例个数。圈复杂度⼤说明程序代码的判断逻辑复杂，可能质量低，且难于测试和维护。因此好的代码⼀定是圈复杂度低的，也是易于测试的。
●
易于迭代演进：没有什么软件是⼀成不变的，好的软件系统应该是易于演进的。单测覆盖⾼的项⽬模块更原⼦化，边界更清晰，修改起来更容易。单测覆盖更全的项⽬重构的⻛险也相对更⼩，相反⼀个没有单测覆盖的复杂项⽬是没⼈敢碰的。
●
更优质的设计：前⾯也提到，好的单测能够提升代码的质量。如果⼀个研发需要给⾃⼰的代码写单测，他就会注重代码的模块化分割，减少过⻓、圈复杂度过⾼的method。下⾯的例⼦就是⼀段没有单测的代码的认知复杂度值（可以理解是圈复杂度的⼀个改良版，从代码是否容易理解的⻆度衡量），超标了⾜⾜三倍。现在回过头来想补单测，脑袋都⼤。
