# 前言
测试是整个项目保障最重要的一环,关系到最终软件的产出质量, 测试对后端来说相对比较熟悉,包括 接口测试,单元测试,性能测试,流量压测 等。但对于前端来说相对比较陌生,由于前端偏向于 GUI 软件性质,同时国内快速的业务迭代节奏,前端做自动化测试的投入产出比不高。
# Jest测试环境源码地址
自动化的收益 = 迭代次数 * 全手动执行成本 - 首次自动化成本 - 维护次数 * 维护成本
@前端进阶之旅: 代码已经复制到剪贴板
解释: 计算公式可以看出来首次投入的成本远远小于首次收益,但是随着项目迭代,收益会越来越明显。
作者认为: 对于前端是否适合做自动化测试,不能一棒子肯定或者否定,需要辩证根据不同的应用场景,项目重要程度(资金相关应用)来判断。下面列举了一些场景
- 数据层SDK: 不涉及UI表现,需要做单元测试,接口覆盖率测试等,它是提供服务给UI层,还需要考虑业务接入版本管理问题。 它的投入产出比远远超出预期。
- 资损类型项目: 对于资金相关的项目,需要重点保障,接口或者UI的改变都可能导致项目严重故障。它的投入产出比也远远超出预期。
- 其他非核心保障项目: 量力而行,不要为了
TDD而TDD
# Jest前端测试框架
Jest 是 Facebook 出品的一个测试框架,相对其他测试框架,最大的特点就是内置了常用的测试工具,比如 自带断言、测试覆盖率工具,UI测试工具,Mock能力 等,同时可以集成很多插件,与主流的软件库配合测试,比如:Typescript, React, Vue等, 真正实现了开箱即用。
# 基本配置
$ npm install --save-dev jest
@前端进阶之旅: 代码已经复制到剪贴板
创建一个 sum.js 文件
function sum(a, b) {
return a + b;
}
module.exports = sum;
@前端进阶之旅: 代码已经复制到剪贴板
创建一个 sum.jest.js 文件
