前端单元测试—孤勇者级教程

《孤勇者》最近火爆的一塌糊涂，占领了小学生、甚至幼儿园，连我家2岁多的儿子尽然也会哼几句。虽然他以为这首歌是奥特曼的主题曲。

回到正题，现代前端项目的工程化、模板化日益壮大，各种类库框架层出不穷，整个行业俨然一副百花齐放百家争鸣的状态。而对于前端单元测试而言，在整个前端领域，实际上单元测试早已不算什么冷门话题，各种测试框架、库已经非常完善。

对于一个前端开发而言，实际上我们不太需要专注所有的这些测试框架、工具。我们只需要按照自己所需（团队、项目所需）选择适合自己的即可。

而怎么选型，实际也非常简单。在现在前端项目多数基于框架的大前提下，直接从官方文档上找单元测试的部分。官方必然会提供测试库或者推荐优秀的 区测试库。

从前端项目层面，无非就是UI的测试(简单的理解成DOM的测试) 、功能性代码测试。

1、UI测试:

很容易理解，前端的项目终究还是会展示在浏览器上，那么所谓的UI测试也就是测试我们写的代码和预期渲染的UI是否一致而已。

结合到我们现在实际项目，多数基于UI框架的情况（比如React），我们只需要跟随官方提供的UI测试途径即可，千万别去直接搜索XX前端单元测试框架之类的。每个框架都有自己的特性，或多或少都会涉及到UI的渲染，比如虚拟DOM、生命周期之类。所以像React官方文档提到的@testing-library/react（也有曾经使用过比较优秀的Enzyme），都会根据React框架特性提供相关的API例如：render、renderHook之类的。

2、功能性代码测试:

简单的说就是一段封装的代码，无论是一个函数或者是一个类。而这段代码多数情况和UI无关，我们只需要要关注功能实现的本身，最简单的就是一个函数，输入什么参数，返回什么值。

在介绍Jest之前，还是先聊一聊何谓单元测试，进行有效的单元测试。

让人闻风丧胆的单元测试

说起单元测试，尤其是对于前端行业的同学们来说，真的算的上是让人闻风丧胆，毕竟单测这个词听上去就是牛逼轰轰。

也经常有勇士会说，劳资React、antd一把梭哈，要个鸡儿的单元测试。

现实工作中，当你接收了别人的代码，大多数人可能会觉得在接手一座屎山，得想办法怎么在屎山上进行雕花，而且还得让山不崩塌。阿西吧，劳资还不如重构了。

stop！又双叒叕扯远了。

好了，别管测试同学嘴里的什么黑盒、白盒、性能、功能。对我们大多数人而言，单元测试，不就是对代码进行测试么。怎么测试呢/p>

代码测试代码

可能你有点明白了，那么问题来了，挖掘机哪家强orry，问题是如何用代码测试代码/p>

举个简单的例子，你写个了函数，判断请求是否成功。因为不可抗拒的因素，你们公司团队里面的后端同学，每个人的接口对于成功返回的定义不一样。有的是通过http 状态码200，有的根据返回值中的success是否为true，有的人返回了一个code字段，值可能为200也可能为”200″。

现实就是这么残酷，前端的小伙伴总是在写这样那样的兼容方案。

对于这样一个常见的函数而言，我们需要如何对其进行单元测试呢/p>

所谓测试，无非就是在特定场景下(我们可以先不用管这个场景是什么)，输入一些值，得到输出值，然后跟期望输出的值进行比对，看是否一致，如果一致则表明这一条测试用例通过。

看这个简单的例子，我们不用管下面的test和expect方法具体是干什么的。

在上面的案例中，我们来逐步分解：

首先定义了一个输入：input。

然后将input作为参数，调用了requestSuccess方法，本次调用得到另一个返回值output。

最后就是判定，判定（也就是所谓的期望/断言）得到的输出值output等于期望的输出值expectOutput。

这是一段最基础的，正常输入值的单元测试代码，我们可以总结出大概的步骤：

1、定义输入值

2、将输入值带上，执行代码，得到输出值

3、对输出值进行断言

这个断言就是说你觉得这个输出值应该是什么，也断言这个输出值和你期望输出值匹配。当然，实际输出值和你的期望输出可能不匹配，那就是表明你的这条用例执行失败。失败的原因可能是你的源代码有问题，也可能是你单元测试的用例代码有问题。

OK，我们了解了最基础的单元测试。那么真正意义的单元测试应该怎么写呢/p>

无非就是写单元测试用例，定义各种输入值，判断和期望输出是否一致，然后进行分析修改。

再回归到上面的requestSuccess方法，上面的测试用例仅仅是验证了正常情况下，当然这种情况可能占大多数，但是单元测试一般就是为了兼容小部分的异常场景。

那么接下来，我们就来分析下一般意义上请求失败场景的测试用例：

好了，到这里，有的同学说，请求正常、请求异常的情况都覆盖了，单元测试完成，可以提交测试，然后进行愉快的摸鱼了。

等等，事情没有那么简单。

测试同学急急忙忙来找你了，说你的程序又崩了，页面空白了。

你让测试同学给你复现了，一步一步debug。原来发现，调用你requestSuccess方法的response参数，尽然为一个空对象： {} 。

你可能会直呼好家伙，后端不讲武德啊（当然可能性很多，可能并不是后端一个人的锅），因为不可抗拒因素，你又得去改代码，一边改一边骂。

改完之后的源码如下，然后你又得意的告诉测试同学已经改完，没有问题了。

结果不一会，测试同学说，你的程序又崩了，页面空白了。

你慌了，自言自语的说道，没问题啊，劳资都写了兼容了，让测试同学给你复现了，一步一步debug。原来发现，调用你requestSuccess方法的response参数，尽然为undefined。你破口大骂，告诉测试是后端的锅，是另一个前端瞎鸡儿调用，和你无关。掰扯了一段时间，你又改了下你的代码:

再回到单元测试的正题上，上面的那些异常情况，在实际项目运行中比比皆是。而除了配合测试同学发现bug然后修改之外，我们在单元测试的时候即可发现，并优化自己的代码。

例如requestSuccess针对这个方法而言，我们先不用去管实际调用时候什么请求成功、请求失败，只去针对这个方法本身，调用requestSuccess方法的参数可能性是非常多的，各种类型的，所以我们可以以每一种类型的输入值作为一条测试用例。

在写了这么多的异常输入的测试用例之后，你会发现你一开始写的requestSuccess不够强大，导致单元测试用例执行失败，所以你可以一遍又一遍的修改你的源码，直至测试用例都通过。

总结： 如何进行有效的单元测试，最简单的做法就是考虑各种异常/边界输入值，编写相应的测试用例，通过单元测试的执行，优化你的代码。

当然做好单元测试，并不仅仅只是说考虑各种异常输入即可，实际还会涉及到开发时候 的考虑(比如常说的测试驱动开发之类的)以及非常多的实现细节，这个可能就需要你慢慢的理解了。

Jest

介绍

官方链接

Jest is a delightful JavaScript Testing Framework with a focus on simplicity.

It works with projects using: Babel, TypeScript, Node, React, Angular, Vue and more!

官方的介绍就是上面2段话，就是说jest是一个让人愉悦的js测试框架，专注于简单性。可以配合babel、ts、node、react、angular、vue等其他库 一起使用。

我们前文提及的什么describe、test、expect方法等等在Jest中都有相应的api。

一、基础教程

安装

可以使用yarn或者npm进行安装

源码开发

这里举了一个简单的例子，实际组件开发需要使用ts以及其他UI测试框架。

例如开发一个基础方法，返回2个参数的和。文件名为sum.ts

测试用例编写

首先我们根据上面的目标文件(sum.js)创建一个测试用例文件– sum.test.js， 测试用例文件名称统一为*.test.js(后缀根据实际场景区分为.js或者.ts或者.tsx)

开始测试

添加下面的部分到你的package.json中

最后，执行yarn testornpm run test命令，Jest将会打印如下信息:

就这样，基于jest的一个基础单元测试流程走好了，Jest的单元测试核心就是在test方法的第二个参数里面，expect方法返回一个期望对象，通过匹配器(例如toBe)进行断言，期望是否和你预期的一致，和预期一致则单元测试通过，不一致则测试无法通过，需要排除问题然后继续进行单元测试。

更多的配置以及命令行参数请参考官方文档下面开始讲解一些核心API。

二、核心API

全局方法

在你的测试文件中，Jest将下面这些方法和对象放置全局环境，所以你无需再显式的去require或者import。当然，如果你更喜欢显式的import，也可以使用例如import { describe, expect, it } from ‘@jest/globals’的方式。

1、test(name, fn, timeout)

test有别名it，两个方法是一样的。

第一个参数是你想要描述的测试用例名称; 第二个参数是包含测试期望的函数，也是测试用例的核心。第三个参数(可选)是超时时间，也就是超过多久将会取消测试（默认是5秒钟）

匹配器

Jest使用匹配器可以让你使用各种方式测试你的代码，Jest中的匹配器实际就是expect方法返回的期望对象中包含的相关方法。官方提供了非常多的匹配器，完善的学习请查看官方文档。

下面摘选了几个最常见的匹配器方法。

1、.toBe(value)

toBe是最简单最基础的匹配器，就是判定是否精确匹配，toBe方法使用了Object.is方法来测试精确相等。

Object.is方法的判定准则可以参考这里

在测试中，你有时需要区分 undefined、 null，和 false，但有时你又不需要区分。 Jest 让你明确你想要什么。

• toBeNull 只匹配 null
• toBeUndefined 只匹配 undefined
• toBeDefined 与 toBeUndefined 相反
• toBeTruthy 匹配任何 if 语句为真
• toBeFalsy 匹配任何 if 语句为假

2、.not

非常容易理解，一般就是反向测试

3、.toEqual

递归检查对象或数组的每个字段

和上面的toBe进行对比，toBe对比俩对象对比的是内存地址，toEqual比的是属性值。

4、expect.assertions

expect.assertions(number) 验证一定数量的断言在某个测试用例中被调用。通常在异步代码测试中非常有用，目的就是为了确保所有的断言被真实的调用了。

比如下面这个例子，如果去掉了expect.assertions(2), 那么测试用例会通过测试，但实际的需求应该是失败的，因为我们最初的期望是catch中的断言也会被调用。而有了expect.assertions(2)，Jest会判断断言实际调用的数量和我们预期是否一致，如果不一致则说明测试失败。

异步代码测试

在JavaScript中执行异步代码是很常见的。 当你有以异步方式运行的代码时，Jest 需要知道当前它测试的代码是否已执行完成，然后它可以转移到另一个测试。 Jest有若干方法处理这种情况。

回调

最常见的异步模式就是回调函数，例如下面的setTimeout方法，下面的测试用例无法通过，原因是Jest无法知道callback具体的调用时间，所以会造成测试已经结束，但是setTimeout的callback还没有执行。

想要解决上面的问题，非常简单，很容易就会联想到消息通知机制，也就是在callback调用的时候通知Jest，表示当前测试用例通过，可以跑下一个测试。

test方法的第二个参数fn，可以添加一个done参数，done是一个方法，调用了done，就是通知Jest测试完成，当然如果你的测试用例中的done方法始终没有执行，那么你的测试也会失败（超时），所以最好的方式就是加上try catch。

Promise

如果你的代码使用了Promise， Jest提供了一种更加直接的方式去处理异步测试。在test第二个参数fn中直接返回一个promise，Jest就会等待这个promise达到resolved状态，如果达到了fulfilled状态，测试将会自动失败。

例如这个案例，此测试用例能够正常的通过

如果promise fulfilled如下，则测试用例会跑失败

当然我们也可以使用catch方法，例如下面这个例子，测试用例就能够正常的通过。

promise代码可以配合匹配器.resolves和rejects一起使用，使用案例如下:

Async/Await

如果你的代码使用了Promise， Jest提供了一种更加直接的方式去处理异步测试。在test第二个参数fn中直接返回一个promise，Jest就会等待这个promise达到resolved状态，如果达到了fulfilled状态，测试将会自动失败。

Mock Functions

Mock 函数简单的说就是模拟一个函数，这个功能很强大，例如nodejs中没有DOM/BOM，及时是jsdom也会缺少一些api，那么我们可以使用mock函数来进行一些测试，具体暂不详细说明。

有两种方法可以模拟函数：要么在测试代码中创建一个 mock 函数，要么编写一个手动 mock来覆盖模块依赖。

Mock Functions Doc

使用 mock 函数

假设我们要测试函数 forEach 的内部实现，这个函数为传入的数组中的每个元素调用一次回调函数。