主流测试框架 Jest 的基础用法

2023-10-11 09:09:04

什么是测试？

测试其实就是在已经开发完成的软件之上采用人工或非人工的方式验证软件是否符合工程预期，是否会造成用户/开发商损失等潜在问题的一种方式。

大多数情况下，我们编写的前端代码都是开发手工自测，又或是提测后由专门的测试人员手工测试。

手工测试当然也是没有问题的，但是通过自动化的测试工具，可以更加快速高效且准确定位问题所在。

自动化测试实际上是运行一段测试代码，去验证目标代码是否满足某个期望。

本文后续的内容中，“测试”一词将专门指代自动化测试。

为什么要测试？

我们进行测试的目的在于，及时发现错误，提高代码质量和开发效率，避免存在 BUG 的代码发布上线造成损失。

测试自动化的好处在于反馈及时，能够极大地提高前端的开发效率。

在我们日常的开发过程中，是不是经常需要在项目跑起来之后去人工测试某些操作或者流程是否能够正常运行？是不是经常需要打断点或者使用 console.log 查看控制台信息来检查某个函数是否执行？

这些需要我们自己手工测试代码的执行结果是否符合预期的场景，完全可以使用自动化测试的脚本代替。

现有的很多成熟的自动化测试框架完全可以模拟我们的手工操作，使用脚本自动运行测试用例，通常只需要几秒就能给出准确的反馈，同时还能侦听代码变化，自动执行项目中发生了变化的代码对应的测试用例，能够极大提高我们的开发效率。

在公司业务和人员变动都比较快的当下，编写自动化测试脚本的收益越来越高。开发者再也不用害怕引入回归 BUG，也再也不用害怕把代码交给他人维护。有了测试脚本的约束，迭代/重构都能更加从容。

测试自动化的收益=迭代次数×全手动执行成本−首次自动化成本−维护次数×维护成本测试自动化的收益 = 迭代次数 \times 全手动执行成本 - 首次自动化成本 - 维护次数 \times 维护成本测试自动化的收益=迭代次数×全手动执行成本−首次自动化成本−维护次数×维护成本

有哪些测试类型？

前端测试主要分为 3 种：单元测试（Unit Test）、集成测试（Integration Test）、UI 测试（UI Test）

三种测试的占比分别为：

现实是，大多数公司的测试金字塔是倒过来的，由人工进行UI 测试反而是最多的，集成测试和单元测试却大多被忽略。

单元测试（Unit Test）

单元测试是最容易实现的：代码中多个组件共用的工具类库、多个组件共用的子组件等。

通常情况下，在公共函数/组件中一定要有单元测试来保证代码能够正常工作。单元测试也应该是项目中数量最多、覆盖率最高的。

能进行单元测试的函数/组件，一定是低耦合的，这也从一定程度上保证了我们的代码质量。

集成测试（Integration Test）

集成测试通常被应用在：耦合度较高的函数/组件、经过二次封装的函数/组件、多个函数/组件组合而成的函数/组件等。

集成测试的目的在于，测试经过单元测试后的各个模块组合在一起是否能正常工作。会对组合之后的代码整体暴露在外接口进行测试，查看组合后的代码工作是否符合预期。

集成测试是安全感较高的测试，能很大程度提升开发者的信心，集成测试用例设计合理且测试都通过能够很大程度保证产品符合预期。

UI 测试（UI Test）

在我学习查阅文献的过程中，我发现国内不少文章都将 UI 测试（UI Test）和端到端测试（E2E Test）混为一谈，认为是同一个测试类型。

事实上，UI 测试（UI Test）和端到端测试（E2E Test）是稍有区别的：

UI 测试（UI Test）只是对于前端的测试，是脱离真实后端环境的，仅仅只是将前端放在真实环境中运行，而后端和数据都应该使用 Mock 的。

端到端测试（E2E Test）则是将整个应用放到真实的环境中运行，包括数据在内也是需要使用真实的。

就前端而言，UI 测试（UI Test）更贴近于我们的开发流程。在前后端分离的开发模式中，前端开发通常会使用到 Mock 的服务器和数据。因而我们需要在开发基本完成后进行相应的 UI 测试（UI Test）。

UI 测试的自动化程度还不高，大多数还依赖于手工测试。

在一些自动化测试工具中有创建快照的功能，也能帮助我们在一定程度上实现 UI 测试（UI Test）的自动化。

哪些项目适合引入自动化测试？

目前市面上的大多数文章都没有讲过这个问题，但事实上这个问题是最值得思考的！

在化学上有一句名言：

抛开剂量谈毒性都是耍流氓。

同理，在前端自动化测试方面，抛开项目类型、软件开发的人员配置和生命周期而谈论自动化测试的好处和必要性，也是耍流氓。

于我个人而言，我比较喜欢写测试代码，当看到测试用例都全部 PASS 都是绿色的时候，非常舒服。

但我猜大部分的开发都会觉得：需求这么多，这么紧急，保证完成需求都已经非常困难了，已经没精力再编写测试代码了。

现实中，我们经常会针对一些活动开发一些一次性的代码模块，这样的代码模块功能简单，且后续继续迭代的可能性低，这种代码就完全没有必要引入自动化测试工具。

适合引入自动化测试的场景：

公共库类的开发维护
中长期项目的迭代/重构
引用了不可控的第三方依赖

这些场景是需要引入自动化测试来对现有代码进行约束的。尤其是中长期项目，迭代/重构时人力回归困难，自动化测试就显得尤为重要！

如何选择测试工具？

现在市面上有很多流行的测试工具，但普遍都存在一个问题：新特性的支持滞后。

前端测试的框架可谓是百花齐放。

单元测试（Unit Test）有 Mocha, Ava, Karma, Jest, Jasmine 等。
集成测试（Integration Test）和 UI 测试（UI Test）有 ReactTestUtils, Test Render, Enzyme, React-Testing-Library, Vue-Test-Utils 等。

主流测试工具比较

框架	断言	仿真	快照	异步测试
Mocha	默认不支持，可配置	默认不支持，可配置	默认不支持，可配置	友好
Ava	默认支持	不支持，需第三方配置	默认支持	友好
Jasmine	默认支持	默认支持	默认支持	不友好
Jest	默认支持	默认支持	默认支持	友好
Karma	不支持，需第三方配置	不支持，需第三方配置	不支持，需第三方配置	不支持，需第三方配置