为什么要单元测试（前⾔）
刹⻋是降低了⻋速还是提升了⻋速？我们通常认为写单测费⼒耗时、耽误研发进度，仿佛在给项⽬“踩刹⻋”。⼤家不妨带着这个问题往下看，详细聊聊为什么单元测试可以让软件开发跑得更快。
什么是单元测试
⼤家对于单测应该并不陌⽣，截取⼀段维基百科的定义帮⼤家唤醒⼀下记忆：
在计算机编程中，单元测试（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），专⻔负责测试平台和⼯具的搭建，不负责具体的业务逻辑测试。
