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

发表于 2年以前 | 总阅读数：305 次

前言

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

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

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

没啥用，没时间，我不会

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

优化流程

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

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

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

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

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

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

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

保证质量

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

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

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

如果把实现功能看成走迷宫，把找到通路看成上线需求， 那么编码实现的过程就像从入口找出口，而单元测试则像从出口找入口。 这种开两个线程 “双向奔赴” 的找通路方法能够用最精准最快的方式找到通路。

单测所保障的不仅仅只是代码的正确性，毕竟大家在边开发边 Debug 的时候已经能验证 99% 的正确性了，而单测更大的地方在于 让我们不得不去思考到一些异常情况 ，这无形中就能增强代码的质量。

优化更新项目的后盾

可能大家对上面这一节也不以为意，我能理解大家的侥幸心理。毕竟在公司里，开发写完 Bug，然后交给测试找出来是大家其乐融融表现。而且不写测试大家过得还挺好的，也没出什么大乱子。

造成这样的错觉在两个方面：一是测试找 Bug，开发再 Debug，这确实能解决燃眉之急，短期内很有效果。二是需求一直不断快速迭代，一期的 Bug，二期还能合着去改，二期改不了还有三期，三期结束了还有四期...... 。

这种永无止境的测试 + 开发模式能在一定程度上让我们的代码 “看起来是有保障的” 。

人肉测试固然好用，但是也有下面的缺点：

使用一次成本非常高
回归测试成本更高
只有到上线功能的时候才会使用一次人力测试来轰炸

由于成本很高，人肉测试一般只会用来测业务功能，并没有太多测试资源可以分配到优化需求、技术需求上。所以对于这类需求只能通过前端开发人员自测，到目前为止也只是优化一个点，然后点点鼠标来自测，效率并不高。一旦优化过程中改出了问题，回滚、和修复的成本又会非常高，这也会助长大家 “不敢优化”、“能不动就不动” 的思想。

如果能有一定量的测试，则有足够强大的信心来支撑项目的优化，也有助于整个项目的未来发展和改进。

测试驱动开发

测试驱动开发（Testing-Driven Development）是敏捷开发中的一项核心实践和技术，也是一种设计方法论。

上面说的单测特点比较偏向于 “防守”，而 TDD 中的测试则偏向于 “进攻”。 TDD 的原理是在开发功能代码之前，先编写单元测试用例代码，在此基础上再补充产品代码。比如要实现 getUserById 这个服务，那么可以先写如下测试，然后再补充 getUserById 的实现：

describe('getUserById', () => {
  it('可以根据 id 返回用户信息', () => {
    // TODO: getUserById 未实现
    const user = getUserById('122');
    expect(user.id).toEqual('122');
  })
})

这种方法在 Node 端非常实用。由于 Node 端要依赖的项非常多，比如数据库、各方接口、配置中心等等。每次用 Postman 去测接口，就会一次性将多个模块以及服务一起测了。如果别的服务还在开发或者有问题，就会直接阻塞了接口的开发。

虽然 Postman 在接口测试的时候很好用，但是它也有如下缺点：

用例不足。 由于 Postman 一般只做简单的接口测试，并不像单测那样会把所有分支情况都枚举
用例无法共享。 虽然 Postman 也能写简单的用例，但是现在每个人的 Postman 会有自己的用例，难以覆盖所有情况
用例无法保鲜。 当接口更新了之后，Postman 的用例可能存在过期的情况

单元测试则很好地填补了这一块，利用单测强大的 Mock 能力先将依赖项都 Mock 掉，开发时可以只关注某个函数、服务的开发，不会受其依赖项干扰：

由于每次提交代码都应该保证测试通过率 100%，所以我们也不会担心这些例子是否过期的问题。

用例即例子

测试用例还有个很好的功能：将使用案例记录在案。

很多时候别人写一些工具函数和方法，使用者是不能一眼就能学会怎么用的。往往这时写函数的人就会说：你看 XXX 文件就知道怎么用了。 但这些 “真实例子” 中通常会夹杂着很多依赖项，无法作用一个最小 Use Case 来理解。

而单测里的每个用例都可以看成一个最小的 example，通过阅读 Test Case 就能马上知道这个函数怎么使用了。 这里举 redux 的 compose 函数的例子：

describe('Utils', () => {
  describe('compose', () => {
    it('composes from right to left', () => {
      const double = (x: number) => x * 2
      const square = (x: number) => x * x
      expect(compose(square)(5)).toBe(25)
      expect(compose(square, double)(5)).toBe(100)
      expect(compose(double, square, double)(5)).toBe(200)
    })
  })
}

就算我们不知道 compose 是用来干嘛的，但是我们很清楚地知道，使用方法就是从右到左地执行回调。

由于每次发布时我们都要保证单测 100% 通过率，所以永远不用担心这个 Use Case 无法使用、过期的问题。

提升个人能力

抛开这些项目质量、优化流程的原因，推荐大家写单测的另一重要原因就是 提升个人能力。

几乎所有 Jest 的入门文章的开头都会有一个非常简单的 Test Case：

expect(1 + 1).toEqual(2)

这很容易让人误以为单测很简单，以为不就是学一个框架那样嘛。然而，只有在真正编写测试用例的时候才会发现单测的难度呈指数级上涨。因为测试的本身是另一个领域，是需要通过不断练习才能掌握测试技巧的。 对前端单测来说，它的难度包括但不限于如下几点：

测试框架与开发框架的不配合。 比如版本冲突问题
模拟环境问题。 比如模拟浏览器环境，往往项目一出现 localStorage，cookie 这些浏览器独有的东西时，Jest 就会报错，很多人受不了直接放弃了
不同框架、库的测试方法都是需要学习的。有的框架 Nest.js 有 @nestjs/testing，React.js 有 react-testing-library。有的库 Redux 又会有自己独特的 testing guide

总的来说，写单测并不像大家想的这么简单，jest 只是个开始的地方。不过，从另一个角度来看，如果你能坚持写好单测，对个人能力也大有裨益：