刹⻋是降低了⻋速还是提升了⻋速？我们通常认为写单测费⼒耗时、耽误研发进度，仿佛在给项⽬“踩刹⻋”。⼤家不妨带着这个问题往下看，详细聊聊为什么单元测试可以让软件开发跑得更快。什么是单元测试⼤家对于单测应该并不陌⽣，截取⼀段维基百科的定义帮⼤家唤醒⼀下记忆：在计算机编程中，单元测试（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依赖，单测相⽐于其他类型的测试更稳定，不会受外部其他模块的不兼容变更影响。因此单测也是最能带给开发者信⼼的测试类型。● 问题更容易定位：单测以最⼩软件单位为边界，出了问题可以缩⼩定位范围。相⽐之下，越是⾦字塔上层的测试类型，定位问题的困难度越⼤。复杂的端到端测试涉及众多的模块，需要⼀⼀排查定位问题