刹⻋是降低了⻋速还是提升了⻋速？我们通常认为写单测费⼒耗时、耽误研发进度，仿佛在给项⽬“踩刹⻋”。⼤家不妨带着这个问题往下看，详细聊聊为什么单元测试可以让软件开发跑得更快。
什么是单元测试
⼤家对于单测应该并不陌⽣，截取⼀段维基百科的定义帮⼤家唤醒⼀下记忆：
在计算机编程中，单元测试（Unit Testing）⼜称为模块测试，是针对程序模块（软件设计的最⼩单位）来进⾏正确性检验的测试⼯作。
单元测试的理念其实⼀直是编程的⼀部分。我们第⼀次编写计算机程序时，肯定会输⼊⼀些样本数据，查看其是否按照你的期望执⾏。如果结果不符合预期，你肯定在代码⾥穿插过⼤量的System.out.println，确保每个原⼦节点都符合预期。这个过程其实就是把复杂问题拆解成原⼦化的问题、逐⼀攻破的过程。单元测试的⽬的也⼀样，是保障软件程序中每个最⼩单位的正确性，从⽽保障由最⼩单位构建起来的复杂系统的正确性。
深⼊展开单元测试的必要性之前，我们先去考考古，看⼀下测试体系是如何演进的。
测试体系的演进
过去的很⻓⼀段时间⾥，软件测试⼤量依赖⼈⼯检测。软件测试甚⾄是⼀个独⽴的⼯种（QA、Tester），QA/tester的⽇常任务就是进⾏⼤量的⼿⼯测试、繁琐易错。
⾃2000年代初以来，软件⾏业的测试⽅法已经发⽣了巨⼤的变化。为了应对现代软件系统的规模和复杂性，业界演变出了开发⼈员驱动的⾃动化测试实践。我们终于可以摆脱⼿动测试的繁琐，⽤软件来测试软件。但过去的实践仍然留下了深远的影响，软件测试还是⼀个独⽴的⼯种，过去的QA演进成了SDET（Software Developer Engineer in Test），我们虽然进化到会使⽤⼯具了，但我们还只是会⽤⼯具的猴⼦。为什么这么讲？因为这种研发/测试分离的模式本身就留下了很多问题。当研发和测试是两个岗位时，交付的边界是软件整体的功能性（functional requirements）和可⽤性。研发只要保证软件整体上功能完备、可⽤就⾏，测试也会聚焦在集成测试和端到端测试上。但软件是由⽆数个最⼩单位构成的，在这种体系下⼈们会忽视最⼩单位的质量、是否可读可测可演进，最终难免“⾦⽟其外，败絮其中”。
基于种种弊端，⾕歌、微软这些对研发质量⾮常重视的公司都在从SDET的2.0时代过渡到 all-in-one 的3.0时代：微软在2015年去掉SDET⼯种，在陆奇带领的Bing中率先提出“combined engineering” 的概念；⾕歌也将SETI替换成EngProd（Engineering Productivity），专⻔负责测试平台和⼯具的搭建，不负责具体的业务逻辑测试。
为什么需要单元测试
在如今的互联⽹时代，软件迭代的速度越来越快，研发的职责也越来越多。DevOps的理念是"you build it, you run it"，研发/测试合⼆为⼀的趋势也可以理解为对"you build it, you test it"的呼吁。当研发要对⾃⼰写的代码质量和测试负责的时候，好的测试实践就必不可少了。
测试⾦字塔
就像盖楼需要从打地基、竖钢筋、灌⽔泥层层往上构建⼀样，测试也有类似的测试⾦字塔架构。下图出⾃《Software Engineering at Google》的测试章节，总结了Google在测试⽅⾯的最佳实践。我们可以看到测试⾦字塔由三层构成，最底层就是单元测试、占⽐80%，是软件系统的地基。再往上是集成测试和端到端测试，分别占15%和5%。因为从下往上占⽐逐层缩减，因此被称为测试⾦字塔（跟盖⾼楼⼀样）。⾕歌推荐的这个⽐例是多年实践出来的结果，意在提升研发的效率（productivity）并提升对产品的信⼼（product confidence）。
测试⾦字塔的核⼼理念之⼀就是“Unit Test First“，每个软件项⽬⾥的第⼀⾏测试应该是单测（TDD甚⾄认为第⼀⾏代码就应该是单测），⽽且⼀个项⽬⾥占⽐最⾼的测试也应该是单测。
图⽚来源：Software Engineering at Google
优秀的软件离不开单元测试
为什么业界都把单元测试放在这么重要的位置？“抓⼤放⼩”，只写端到端测试不⾹吗？这⾥我们来展开讲讲单测的好处。
提升debug效率
单元测试是软件⼯程极佳的地基，因为它们快速、稳定，并且极⼤地缩⼩了问题范围，提升故障诊断的效率。
● 测试更快：单测没有其他外部依赖，跑的快，可以提供更快的反馈环，更快的发现并修复问题。
● 测试更稳定：同样因为0依赖，单测相⽐于其他类型的测试更稳定，不会受外部其他模块的不兼容变更影响。因此单测也是最能带给开发者信⼼的测试类型。
● 问题更容易定位：单测以最⼩软件单位为边界，出了问题可以缩⼩定位范围。相⽐之下，越是⾦字塔上层的测试类型，定位问题的困难度越⼤。复杂的端到端测试涉及众多的模块，需要⼀⼀排查定位问题。
提升代码质量
代码是写给⼈看的，好的代码应该是易读、易改、易维护的。写单测的过程其实就是吃⾃⼰代码狗粮（dogfood）的过程，从⽤户/研发视⻆去使⽤⾃⼰的代码，帮助我们提升代码质量。
● 好的代码是易测的：业界很早就提出了圈复杂度（Cyclomatic complexity）的概念，⽤来衡量⼀个模块判定结构的复杂程度，其数量上表现为独⽴路径的条数，也可理解为覆盖所有的可能情况最少使⽤的测试⽤例个数。圈复杂度⼤说明程序代码的判断逻辑复杂，可能质量低，且难于测试和维护。因此好的代码⼀定是圈复杂度低的，也是易于测试的。
● 易于迭代演进：没有什么软件是⼀成不变的，好的软件系统应该是易于演进的。单测覆盖⾼的项⽬模块更原⼦化，边界更清晰，修改起来更容易。单测覆盖更全的项⽬重构的⻛险也相对更⼩，相反⼀个没有单测覆盖的复杂项⽬是没⼈敢碰的。
● 更优质的设计：前⾯也提到，好的单测能够提升代码的质量。如果⼀个研发需要给⾃⼰的代码写单测，他就会注重代码的模块化分割，减少过⻓、圈复杂度过⾼的method。下⾯的例⼦就是⼀段没有单测的代码的认知复杂度值（可以理解是圈复杂度的⼀个改良版，从代码是否容易理解的⻆度衡量），超标了⾜⾜三倍。现在回过头来想补单测，脑袋都⼤。
