前言

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

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

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

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

没啥用，没时间，我不会

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

优化流程

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

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

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

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

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

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