来聊聊我们为什么要写单测

前言

哈喽，大家好，我是海怪。

最近在组里我又领了一个新任务：前端单元测试。

关于这个话题在很早的时候就想和大家聊了，奈何一直没机会。对于我个人来说，我是非常喜欢写单测的。最近还买了本《软件测试》的书，算是再次复习一下大学时学过的专业课，平时在捣鼓一些个人项目的时候也会做一些基础的单测。

一谈到单测，可能大家的第一反应都是敬而远之。

没啥用，没时间，我不会

我承认写单测是个非常有挑战性，且难度不小的活，但 我依然推荐大家尝试去写一写单元测试，因为它所带来的好处不仅仅是大家想的那么简单：“只是 Bug 少了一点”。 所以，今天我会尝试从另外一些角度来讨论单测可以给我们带来哪些好处。

优化流程

接着刚刚说到的 “只是 Bug 少一点” 这句话，可能大多数觉得单测就是在提测前减少一点 Bug 而已：

这样的想法确实是最直观的。但这只是想到了第一层，如果我们把 开发流程所有步骤 都加进来，会发现是这样的：

在 开发过程 后面，几乎每个流程都可能抛出 Bug。越是到后面流程才抛出的 Bug，程序员就越是要投入比开发阶段更大的时间和业务，而且所承受的风险也是最高的。

或许大家会想：不就改个 Bug，改几行而已。 可是大家有没有想过在跟测的过程中，很可能你已经开始另一个需求的评审了！ 此时的你在解决突然插入的 Bug 的时候，心态还会像刚开始写代码时候那么轻松么？

实际上，还有更多的隐性成本没有考虑，比如反复确认产品逻辑、反复确认交互设计、反复确认前后端接口设计、各端对产品的理解。 有的时候，你就会发现这样很魔幻的场景：明明是一个字段的展示问题，竟然要花上一上午，拉了 4、5 个人来开会核对的情况。

下面这张图，也在说明两个问题：一是 85% 的缺陷都在代码设计阶段产生；二是发现 Bug 的阶段越靠后，耗费成本就越高，呈指数级别的增长。这种 “指数成本” 的案例也经常发生，当我们改正一个 Bug 的时候，可能随之而来又会多出 3 个 Bug，俗称：改崩了。

所以，在早期的单元测试就能发现bug，不仅可以省时省力，在开发流程上提高效率，也能降低反复修改出现的风险和时间成本。

保证质量

这一节主题就是大家经常想的：减少 Bug 率。我们不妨来想一个问题：什么才是 Bug？ 相信所有开发人员都不愿意写 Bug，在 《软件测试》 这本书中将 Bug 描述成 “软件缺陷”，里面说道：

大多数的 “软件缺陷” 并非源自编程错误，对众多从小到大的项目进行研究而得出的结论往往是一致的，导致软件缺陷最大的原因是产品说明书！见下图

大多数的产品还是能够写出一份清晰明了的需求单的，奈何 ta 也不可能把所有情况想都枚举出来，这也导致了开发时很容易出现考虑不周全的情况。往往能够发现异常情况的人要么是测试、要么是交互视觉、要么是后期产品体验。 那到这个时候才发现的问题，然后再去修复又会出现的 指数爆炸的成本。

如果把实现功能看成走迷宫，把找到通路看成上线需求， 那么编码实现的过程就像从入口找出口&