过去的很⻓⼀段时间⾥，软件测试⼤量依赖⼈⼯检测。软件测试甚⾄是⼀个独⽴的⼯种（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甚⾄认为第⼀⾏代码就应该是单测），⽽且⼀个项⽬⾥占⽐最⾼的测试也应该是单测。
