Jest单元测试进阶
Jest 命令行窗口中的指令
在学习Jest单元测试入门的时候，给Jest命令提供了一个参数 --watchAll, 让它监听测试文件或测试文件引入的文件的变化，从而时时进行测试。但这样做也带来一个问题，只要改变一点内容，Jest就会把所有的测试都跑一遍，有点浪费资源。有没有可能对--watchAll模式进行进一步的优化？在命令窗口中执行npm run test 看一看就知道了, 测试完成后，你会发现还有很多提示(Watch Usage)，这些就是对--watchAll模式的优化
Press f to run only failed tests. 按f 键，只测试以前失败的测试。执行npm run test 的时候，发现有一个测试失败了，这时我们只想测试这个失败的测试，可以按f了。演示一下，随便把一个测试用例改为错误，比如 把request 的mock 改为name: 'jason'
jest.mock('request', () => { return (url, callback) => { callback(null, 'ok', {name: 'jason'}) } });
测试重新跑了一遍了(watchAll 模式)，命令窗口中显示了错误, 并且在最下面显示press w to show more, 同时光标在闪烁，等待输入。此时按w, 显示了上图中的内容，再按f， 只跑了失败的测试，因为三个测试skipped 了， 当然肯定还是有错误，因为我们还没有修改测试代码
修改测试代码到正确并保存，它只跑了刚才失败的测试。但此时你再修改func.test.js 文件或其它测试用例，发现测试不会再运行了，显示No failed test found，按f键退出
因为f模式是测试以前，就是上一次，失败的测试，我们已经修改好了上一次失败的测试，所以它就不会再进行测试了。按f， 重新回到了watchAll 模式。
总结一下，f 模式的使用就是，npm run test 有失败测试，按f, 修改失败到成功，再按f 退出该模式。
Press o to only run tests related to changed files. 按o ，只会去测试和当前被改变文件相关的测试。但这时，你按o，发现报错了。为什么呢？因为让Jest 去测试改变文件中的测试，但Jest它自己并不知道哪个文件发生了变化，Jest本身，不具备比较文件改变的功能，那怎么办？需要借助git. 因为git 就是追踪文件变化的，只要把工作区和仓库区的代码一对比，就知道哪个文件发生变化了。因此需要把项目变成git 项目。在根目录下，先建.gitignore 文件，再执行git init， 把项目变成git 项目，否则会把node_modules 放到 git 仓库中。为了演示，把fetchData的测试从func.test.js拆分为出来，就叫fetchData.test.js
jest.mock('request', () => { return (url, callback) => { callback(null, 'ok', {name: 'sam'}) } }); const fetchData = require('./func').fetchData; test('should return data when fetchData request success', () => { return fetchData().then(res => { expect(res).toEqual({name: 'sam'}) }) })
git add . and git commit -m "init git" 把文件提交到git 仓库。执行npm run test 启动测试，按o 进入到o 模式, 可以看到如下提示，没有文件发生变化。
这时更改一个文件，如forEach 加一个空行，看一下控制台，只有func.test.js 测试文件执行了，其它测试文件并没有执行， 再改一个fetchData.test.js 文件，两个测试文件执行了，还是只跑改变文件中的测试。这时让我想起了jest 命令的另一个参数，--watch, o 模式 不就是--watch 吗。把package.json 中的 --watchAll 改成 --watch
"scripts": { "test": "jest --watch" },
重新启动npm run test, 有了-a模式，run all the tests, 这不就是--watchAll, 原来 --watch, --watchAll, a 模式，o 模式，是这样互通的。
再看一下p, 按照文件名执行测试，我们提供一个文件名，它只会对该文件进行测试，可以使用正则表达式来匹配文件名。按p, 提示输入pattern, 再输入fetch, 它就会用fetch 去匹配所有的测试文件名，找到了fetchData.test.js 测试文件，然后它就执行了。如果找不到任何测 试文件，它什么测试都不会执行。
t 则是匹配的test 名字，每一个test 都有一个描述，这个描述可以称之为test 的名字。提供一个test 的名字，它只跑这个test，用法和p 一样。
q 退出watch， enter 就是跑一次单元测试，无论是在什么模式下，只要按enter，就会跑一次对应模式的测试。
Jest 快照测试
传统的单元测试通常都是，执行代码，断言比较，看看是不是和预期的效果一致。但这种断言测试在某些情况下不太合适。比如配置文件，配置文件本来就是放在那里，不用执行代码，如果进行比较断言，就是它和它本身进行比较，肯定相等，这种测试不是太好。之所以对配置文件进行测试，就是希望它不要被随便改了。如果改了，要通知到同事。还有就是UI，它就长这样，不用断言了，我们更希望UI 做好以后，不要随便改了，确定要改了，那就通知大家。对于这两种不希望被改的场景，更好的测试办法，就是把它保存起来，以后每次测试的时候，就和保存的内容进行对比，看有没有改变。把某一时刻的内容保存起来，就是形成了快照，快照就是用来保存的某一时刻的状态。Jest的快照测试也是如此，保存与对比。它提供了一个toMatchSnapshot() 方法，当第一次运行测试的时候，没有快照，那就把这一时刻的状态保存起来，形成快照。以后再运行测试的时候，它会生成一个新的那一时该的快照与以前的快照进行比较，如果两者一致，就表明内容没有变化，测试通过，如果两者不一致了，就表示内容发生改变，jest 就会报错了。新建config.js，
export const axiosConfig = { devUrl: 'local', productUrl: '/', header: { 'accet': 'json' } }
config.test.js 写一个快照测试
import { axiosConfig } from './config';
test('axios config', () => {
expect(axiosConfig).toMatchSnapshot();
})
npm run test, 这时项目根目录下生成了一个文件夹__snapshots__,下面有一个config.test.js.snap, 这就是生成的快照文件，它的名字和测试文件的名字一致。打开看一看，它就是把文件内容用字符串的形式保存起来了。这时不管运行多少次npm run test, 测试都会通过，因为config.js 没有改。改变一下，比如加一下id
export const axiosConfig = { devUrl: 'local', productUrl: '/', header: { 'accet': 'json' }, id: '23' }
这时jest 报错了，如果确定要改成这样，那就需要更新快照了。命令行中按w，多了u和i, u就是表示更新失败快照，i 则表示交互式的更新快照。 此时按u, 测试重跑，更新成功。那什么是交互式的更新快照呢？它是针对多个失败的快照而言的，按i，你可以一个一个进行快照的确认和更新，如果按u，则是一次性全部更新所有快照，可能不是你想要的结果。如果两个快照失败了，一个要更新，一个不要更新，那u就无能为例了，只能使用i。在config.js再写一个配置
export const fetchConfig = { method: 'post', time: '2019' }
那测试文件中，再写一个快照测试
test('fetch config', () => { expect(fetchConfig).toMatchSnapshot(); })
这时测试肯定没有问题，同时改一下两个配置文件，id改了'24'， time改为'2019/11', 2个快照测试都失败了。此时按i, 你会发现只显示一个快照失败，表示这次只确认这一个失败的快照，它也提示了u更新快照，s 跳过这个测试，q退出该交互模式，如果更新,按u，此时又显示了一个失败的快照，再按u，更新完毕。这就是交互式，一个一个的更新，更为灵活。
但有的时候，time是动态生成的，比如fetchConfig中的time 改成new Date(), 每一次跑单元测试的时候，time 都不一样，jest肯定报错。这时可以给toMatchSnapshot() 方法传递一个参数{ time: expect.any(Date) 表示什么时间都可以，就不要匹配时间了。
test('fetch config', () => { expect(fetchConfig).toMatchSnapshot({ time: expect.any(Date) }); })
Jest Manual Mock
在以前mock 函数的时候，我们都会把mock 函数的实现放到测试文件中。manual mock 则是创建一个文件夹__mocks__, 把所有mock 函数的实现放到该文件夹下，不过这里要注意 __mocks__ 文件夹的位置，你要mock 哪个文件中的函数，__mocks__文件夹就要和哪个文件放到同一级目录中。新建__mocks__文件夹之后，再在其下面新建一个和要mock的文件的同名文件，在这个文件中就可以写函数的实现。 比如我们要mock func.js 中fetchData, 那就要在func.js 同一级目录(根目录)中新建__mocks__, 然后在其下面建func.js 文件件，在func.js 中就可以mock fetchData。
当在测试文件中，jest.mock(./func.js)，然后引入fetchData 时，jest 自动会到__mocks__ 目录中找func.js 文件，取里面的fetchData 函数，这就是mock的函数了。fetchData.test.js
jest.mock('./func'); const fetchData= require('./func').fetchData; test('should return data when fetchData request success', () => { return fetchData().then(res => { expect(res).toEqual({name: 'sam'}) }) })
这种mock 有一个问题，在fetchData.test.js 里面测试 一个add.
const add = require('./func').add; test('add', () => { let sum = add(3, 2); expect(sum).toBe(5) })
测试报错，add is not a function. 这是因为jest.mock('./func.js'); 整个func.js 模块被mock了，require('./func').add 的时候，它是从mock 的func.js 模块中，就是__mocks__
文件下的func.js 里面去找add, 很显然，没有，所以报错了。怎么解决，不使用require了，使用jest.requireActual()， 字面意思，require真实的，就是从真实的模块，而不是从mock 的模块中引入。 jest.requireActual('./func').add, 从真的func.js中引入add.
const add = jest.requireActual('./func').add;
有mock 就有unmock(), 取消mock。
jest.unmock('./func.js');
如果你mock 的是node_modules 第三方模块，那就要在根目录（node_modules同级目录）新建__mocks__ 文件夹，然后在其下面新建和要mock 模块同名的文件句,如mock request.js 模块，使用request.js 的时候，我们使用的是require('request'), 所以就可以在__mocks__ 文件中建一个request.js.
// 自动mock 这个模块(request) 所有暴露出来的方示 jest.genMockFromModule('request'); let request = require('request'); request = jest.fn((url, fn) => { fn('error', 'body', {name: 'sam'}); } ) module.exports = request;
当mock的node_modules中的模块时，jest 是自动mock, 执行测试的时候，如果看到你require 第三方模块，它自动会从__mocks__文件夹中找这个模块，肯定是mock的模块。
mock timer
它主要是针对定时器setTimeout, setTimeinterval 提出的。比如在代码中有一个函数需要3s 之后执行，那么在测试的时候，就要在3s以后，测试函数有没有执行,有点浪费时间
function lazy(fn) { setTimeout(() => { fn(); }, 3000); } test('should call fn after 3s', (done) => { const callback = jest.fn(); lazy(callback); setTimeout(() => { expect(callback).toBeCalled(); done() }, 3001); })
所以jest 提供了mock timer 的功能，不要再使用真实的时间在这里等了，一个假的时间模拟一下就可以了。首先是jest.useFakeTimers() 的调用，它就告诉jest 在以后的测试中，可以使用假时间。当然只用它还不行，因为它只是表示可以使用，我们还要告诉jest在哪个地方使用，当jest 在测试的时候，到这个地方，它就自动使用假时间。两个函数，jest.runAllTimers(), 它表示把所有时间都跑完。jest.advanceTimer() 快进几秒。具体到我们这个测试，我们希望执完lazy(callback) 就调用， 把lazy函数中的3s时间立刻跑完。可以使用jest.runAllTimers();
jest.useFakeTimers(); // 可以使用假函数 test('should call fn after 3s', () => { const callback = jest.fn(); lazy(callback); jest.runAllTimers(); // 在这里，把lazy函数里面的3s立即执行完 expect(callback).toBeCalledTimes(1); })
但如果我们的lazy 函数中有两个setTimeout 函数，runAllTimers 就会有问题，因为它把所有时间都跑完了，不管有几个setTimeout. 把lazy 函数改为如下
function lazy(fn) { setTimeout(() => { fn(); setTimeout(() => { fn(); }, 2000); }, 3000); }
你会发现fn 被调用了两次。但有时，只想测试最外层的setTimeout有没有被调用，这时就要用jest.advanceTimersByTime(3000)
test('should call fn after 3s', () => { const callback = jest.fn(); lazy(callback); jest.advanceTimersByTime(3000); // 快进3秒 expect(callback).toBeCalledTimes(1); })
没有问题，如果再想测试内层的setTimout 有没有被调用，再快进就好了，不过要注意快进的时间，2s， 因为它会在上一个advanceTimerByTime的时间基础上进行快进
test('should call fn after 3s', () => { const callback = jest.fn(); lazy(callback); jest.advanceTimersByTime(3000); // 快进3秒 expect(callback).toBeCalledTimes(1); jest.advanceTimersByTime(2000); // 再快进2秒 expect(callback).toBeCalledTimes(2); })
现在你会发现，如果在一开始的时候，直接快进5s，它的效果就和runAlltimers 一样了。最后一个问题，就是多个测试中都使用advanceTimersByTime，因为它是累加时间的，第二个测试的advanceTimersByTime的时间肯定会在第一个测试中的advanceTimersByTime 时间上相加。解决办法是beforeEach(). 在beforeEach 中调用jest.useFackTimers，每次测试之前，先初始化timer，把timer归零
beforeEach(() => { jest.useFakeTimers(); // 可以使用假函数 }) test('should call fn after 3s', () => { const callback = jest.fn(); lazy(callback); jest.advanceTimersByTime(3000); // 快进3秒 expect(callback).toBeCalledTimes(1); jest.advanceTimersByTime(2000); // 再快进2秒 expect(callback).toBeCalledTimes(2); }) test('should call fn after 3s', () => { const callback = jest.fn(); lazy(callback); jest.advanceTimersByTime(3000); // 快进3秒 expect(callback).toBeCalledTimes(1); jest.advanceTimersByTime(2000); // 再快进2秒 expect(callback).toBeCalledTimes(2); })
