前端单元测试入门与最佳实践（1）
前言当你开启一个新项目的时候，相信你一定会对自己的每一个变量命名、参数设计、目录结构都经过了反复斟酌和多次修改，你希望自己的设计哲学能够被后续的开发者理解并且参照着继续维护下去。然而随着需求数量的增加，迭代周期的拉长，开发人员的更替，最终代码风格和代码质量都会逐渐下降。于是研发同学开始设计出各类工具希望能够对代码的质量进行一定的限制，提前规避技术债务。
常见治理工具
预期收益
·规范代码质量，在代码上线前降低 BUG 风险；
· 优秀的单元测试用例也是最佳的代码使用文档；
· 可以放心的重构代码，可以放心的将代码模块交接给新同学开发。
技术选型
为什么是单元测试？
在做自动化测试调研的过程中，有不少同学提出过这个问题。有些同学认为单元测试的覆盖面太小，提升单测覆盖率所需要付出的时间成本相比于编写 E2E 测试要高出不少，有些同学认为单元测试更加适合对工具函数进行测试，不擅长对 pages 或 components 进行测试，同时也向我推荐过不少 E2E 的测试框架和工具，如：NightWatch、Selenium、Puppeteer 等，接下来我们分别来进行对比。
E2E 测试
关于 E2E 测试的定义及使用介绍在社区中已经有许多的内容，这里不再重复介绍。
优点：
· 自动化测试的运行环境和用户所处环境更接近；
· 编写测试用例需要兼容的环境问题以及数据 mock 相对较少；
· 编写相对较少的测试用例即可覆盖较多的代码行数。
缺点：
· 需要开发环境的上下游都能提供稳定的测试环境
上下游中的某个环节环境挂掉，整体测试流程会被阻断。
· 执行测试需要的时间较长，降低流水线的执行速度
需要执行完毕前置用户操作，才能测试到后续的场景；
需要等待服务端接口响应才可继续执行。
· debug 相对困难
测试过程中如遇到账号风控，或者不符合预期的广告弹窗，原测试用例无法执行。
· 触发特殊逻辑分支的成本较高
如果需要测试某个极特殊且小概率的场景，需要提前配置好专用测试账号，或为代码预留后门才能保证测试用例的稳定执行。
· 测试环境需要安装的依赖较多且沉重
单元测试
上图摘自《Testing Vue.js Applications 1st Edition》
优点：
· 测试环境的稳定性更强，对上下游环境的依赖较少；
· 测试执行速度较快，不需要启动浏览器环境即可执行测试；
· 极强的灵活性，可以自主模拟各种小概率场景。
缺点：
· 需要编写的测试用例较多，编写初期较为痛苦；
· 缺少浏览器环境下的全局对象及方法，如测试涉及 window、fetch、storage 等操作需要开发者自行 mock。
推荐使用什么？
Jest
测试框架对比：
基本用法：
description("src/pages/components/auth", () => {
test("should return 100", () => {
// 测试代码
// const result = ...
expect(result).toEqual(100);
});
it("should not return 100", () => {
// 测试代码
// const result = ...
expect(result).not.toBe(100);
});
});测试运行效果：
页:
[1]
