反⾯模式和常⻅误区
上⾯提到了写单元测试的种种好处和业界的最佳实践。我们也列举⼀下常⻅的反⾯模式和误区，帮助⼤家更好的规避类似错误。
测试的反⾯模式（anti-pattern）
反⾯模式⼀：冰激凌筒模式
只关注⽤户视⻆的端到端测试、⼤量依赖QA测试都会产⽣如下图所示的反⾯模式。很不幸，这也是在过去的测试体系影响下最常⻅的模式。冰激凌筒模式下，测试套件通常运⾏缓慢、不可靠、难以使⽤。缺失底层的单测也会让项⽬变得⾮常难维护，很难做⼤的改动。
反⾯模式⼆：沙漏模式
沙漏模式下，项⽬中有⼤量的单元测试和端到端测试，但缺乏集成测试。虽然它不像冰激凌筒那么糟糕，但仍会导致许多端到端测试失败，这些失败本可以通过⼀套中等范围的测试更快更容易地捕捉到。当模块间紧密耦合，使得依赖项很难单独实例化出来的时候，就会出现沙漏模式。
测试的常⻅误区
常⻅误区⼀：⽤户第⼀，测试覆盖⽤户的需求⾜够了
这个误区下会认为，端到端测试是站在⽤户视⻆做测试，把⽤户要的功能点都覆盖到就⾜够了。这种误区导致的结果就是冰激凌筒反⾯模式。虽然软件交付的最终功能是给客户使⽤的，但构成软件的代码本身是给⼈（研发）读的、需要⼈去维护。外部⽤户是⼈，内部⽤户也是⼈。
常⻅误区⼆：All-in端到端测试，节省了80%的测试代码量，赢麻了
从短期来看，不写单测可以节省80%的测试代码量和⾄少50%的研发时间。但只要项⽬复杂起来，时间线拉⻓，过去⽋的历史债务（technical debt）早晚要加倍奉还。等到真正需要还债的时候再去补，可能为时已晚。
常⻅误区三：写单测的⼈都弱爆了，我⻓这么⼤还没写出过bug
这篇⽂章可能不适合你。不过软件开发是个团队项⽬，你写的代码最终也会落到别⼈⼿⾥去升级维护，没有测试覆盖的代码是没⼈敢碰的。
总结
结尾处再快速总结⼀下。本⽂从测试体系的历史⼊⼿，讲述了从⼿动测试 -> 靠别⼈⾃动化测试 -> 靠⾃⼰⾃动化测试的历史演化进程，也尝试着从这个视⻆解释为什么⼤家过去不重视单元测试。之后我们分别讲述了什么是单元测试，业界的⾦字塔测试最佳实践，并且深⼊讲解了单元测试的种种好处。最后我们列举了常⻅的反⾯模式和误区，帮助⼤家快速识别规避常⻅的错误。
如果把测试体系的演进类⽐为⼈类的进化，那么我认为⽆单测覆盖和有充分单测覆盖的软件就好⽐爬⾏的古猿和直⽴⾏⾛的现代⼈类。由衷希望⼤家能够重视单元测试、写好单元测试，让我们的软件尽快从爬⾏进化成奔跑，迸发出源源不断的⽣命⼒、创造出更多价值！
