前端单元测试-jest入门实践前端单元测试-jest入门实践

前言单元测试是用来测试程序中一小块功能的，比如说一个函数、一个类。它能很显著地提高项目的代码质量，降低出现 Bug 的频率，并且也利于维护代码。
话虽如此，但是绝大多数人是不愿意去写单测的。。不过不影响，多学点不是坏事。
背景就不多做介绍，主要是实践。
正文本次项目中，我用的框架是Jest。用法比较简单，这里简单介绍一下：
什么是单元测试？
单元测试（Unit Testing）又称为模块测试，是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。
TDD:测试驱动开发
先编写测试用例，在测试用例的指导下去完善功能，当测试用例编写完并且都通过测试之后，相应的功能也就做完了。例如函数和组件库。但通常在代码发生变化的时候，测试用例也要进行相应的调整。
BDD:行为驱动开发
测试用例模拟用户的操作行为，通常在完成业务代码开发之后，以用户的操作为指导编写测试代码。当测试用例跑通之后，就可以认为系统的整体流程已经流畅。BDD的模式适用于平时的业务代码开发，因为业务的需求有可能变更频繁，但操作流程有可能不会变化，当业务代码发生变化的时候，可以使用原来的测试用例继续跑代码，节省了开发时间。
TDD负责方法类、独立组件的测试。BDD则负责整体业务模块的测试。
为什么需要单测？
现状：
缺乏意识：没有单测意识，很多代码没有单测
缺乏设计：模块缺乏设计，相互耦合，写单测困难
测试困难：升级公共 API，人工测试验证困难
测试不全面：部分代码分支众多，人工测试没办法覆盖所有分支
怎么衡量单测完善度？
单测完善程度的衡量用覆盖率来衡量

文章图片

单测的意义
能力建设：一个具备开发经验的开发人员，基本上都会编写单元测试。即便不会，可以通过培训来快速达成。从学习曲线上看，单元测试很容易上手。
提升效率：能够通过 mock 数据，及早发现问题，而越早发现Bug，造成的浪费就会越小。
追求卓越：单元测试可以充当一个设计工具，它有助于开发人员去思考代码结构的设计，让代码更加有利于测试。
测试更全面：能够覆盖 QA 测试覆盖不到的情况，比如各种 if 分支、异常处理。
更有信心：升级公共 API 时，如果依赖这个 API 的所有代码单测都能通过，那我们对这次代码升级是更有信心的。
理念介绍到此结束，接下来是相关实践
1. 断言
在Jest中使用最多的就是断言库，我们可以用它来测试目标函数的输出是否与预期一致。

test("测试 2 + 2 = 4",()=>{ expect(sum(2,2)).toBe(4) }) test("测试函数返回对象为 {name: 'zhi'}",()=>{ expect(getName()).toEqual({name:"zhi"}) })

更多可以查看官方文档。
2. 异步代码测试
通常会有两种写法：

回调函数
函数返回promise

在测试异步代码的时候，通常返回的数据是不确定的，因此我们只需要测试异步代码是否正常返回数据即可。
对于回调函数，如果像同步函数一样测试，是没有办法获取正确的断言结果

export const funcA = (callback: (data: number) => void): void => { setTimeout(() => { callback(1); }, 1000); }; ? test('funcA', () => { funcA((data) => expect(data).toEqual(2)); }); ?

即使是这样，我们的单测也可以通过。
这是因为jest在运行完funcA后就直接结束了，不会等待setTimeout的回调，自然也就没有执行expect断言。正确的做法是，传入一个done参数：

test('funcA', (done) => { funcA((data) => { expect(data).toEqual(2); done(); }); });

在回调执行完之后显式地告诉jest异步函数执行完毕，jest会等到执行了done()之后再结束，这样就能得到预期的结果了。
对于promise，只需要在test用例结束时，把Promise返回即可。

export const funcB = (): Promise => { return new Promise((resolve) => { setTimeout(() => { resolve(1); }, 1000); }); }; ? test('funcB', () => { return funcB().then((data) =>expect(data).toEqual(1)); }); // 也可以使用await test('funcB', async () => { const data = https://www.it610.com/article/await funcB(); expect(data).toEqual(1); });

对于promise抛出异常，则需要使用 .catch 方法。这里有个需要注意的地方。添加 expect.assertions 来验证一定数量的断言被调用。否则，一个fulfilled状态的Promise不会让测试用例失败。

test('the fetch fails with an error', () => { expect.assertionsassertions(1); return fetchData().catch(e => expect(e).toMatch('error')); });

3. Mock
【前端单元测试-jest入门实践】如果我们需要测试回调函数是否执行，可以用mock。在这里想基于实践介绍一下mock的用法。
场景1：一个react hooks使用了react-router的useLocation。我们想模拟这个有没有调用

import { renderHook, act } from '@testing-library/react-hooks'; let mockLocation = jest.fn(() => { return { search: "test" } })jest.mock("react-router-dom", () => { return { useLocation: () => mockLocation() } })// 使用test("useTabChange", () => { const { result, rerender } = renderHook(() => useTabChange()); expect(mockLocation).toBeCalled() })

我们甚至可以给任何方法内部的函数模拟返回
例子2: 在业务中用到了一个'opa-fe-base'的库，我们需要模拟一下返回

import { renderHook, act } from '@testing-library/react-hooks'; let mockFn = jest.fn() jest.mock("opa-fe-base", () => ({ storeAPI: { getEntity: () => mockFn() } })) import useCountry from '../useCountry' ? describe("useCountry", () => { test("useCountry to return SG", () => { const { result, rerender } = renderHook(() => useCountry()) expect(result.current).toBe('SG') mockFn = jest.fn(() => { return { country: "ID" } }) rerender() act(() => { expect(result.current).toBe('ID') })}) })

上述例子可以看到，我们模拟了'opa-fe-base'这个库返回了一个包含
storeAPI的对象，对象内部还有个mock的方法。我们可以通过改变mock方法的返回来判断返回是否达到预期。
注意：需要测试的函数import写在我们mock的下面
最近在写单测的时候发现window.URL.createObjectURL事件可以直接使用jest.fn进行模拟。但是document的事件却模拟不成功，查询文档发现可以使用jest.spyOn。
场景3：通过jest.spyOn 模拟document事件

const spyFn = jest.spyOn(document, 'createElement') const mockRevoke = jest.fn(); ? describe("downloadBlobFile", () => { beforeEach(() => { window.URL.createObjectURL = jest.fn((blob) => { return blob }) window.URL.revokeObjectURL = mockRevoke; }) test("downloadBlobFile must be called", () => { downloadBlobFile({}); expect(spyFn).toBeCalled() expect(mockRevoke).toBeCalled(); }) ? test("download createObjectUrl use", () => { downloadBlobFile("test"); expect(window.URL.createObjectURL.mock.calls[0][0]).toEqual('test') }) })

4. 快照
帮助我们确保在维护代码的过程中不会对组件的 UI 进行改变。