前言
恰好在公司一个项目中需要配置单元测试，借着机会学习了一下。经过对比最终选用了Facebook的jest测试框架，本文包含以下几点内容
- 什么是单元测试？
- 什么时候使用单元测试？
- 如何使用单元测试？
什么是单元测试（Unit Testing）？
什么是单元？软件设计的最小单位。在过程化编程时，它可以是单个程序、函数、过程等；在面向对象的编程中，它可以是方法，包括基类、抽象类、子类中的方法等。 所谓单元测试，就是针对软件设计的最小单位来进行正确性检验的测试工作。 除了单元测试之外，还有集成测试、系统测试、验收测试等测试类型，它们作用在项目开发的不同阶段，测试目的也不尽相同。
什么时候使用单元测试？
软件设计有两个终极目标：
- 实现需求；
- 代码质量及可维护性。
所以要判断什么时候使用单元测试，就是看是否实现了这两个目标。举例说明，考虑如下两个场景：
- 输出Hello World，几行代码；
- 某公司的管理系统，2w+代码，上千个函数及方法。
对于场景1，需求简单，无论是代码质量，还是可维护性，都相当高，这样的场景显然没有必要添加单元测试。对于场景2，你能保证组成这个系统的上千个函数和方法没有BUG吗？即使你天赋异禀，能够让如此复杂的代码不失控，那么遇到需求迭代、工作交接等场景时，能保证变更不引入新的问题么？（稍有工程经验的人应该都体会过一边修bug一边写bug的绝望）
所以我们的结论是，如果你的场景需求简单、个人开发、代码量小，或者你是准备干一票跑路，那么单测也许显得不那么重要。但是如果系统的复杂度终究会超过个人的精力，那么你需要单元测试这样的工具帮助你规避潜在的风险。最能体现单元测试意义的场景，就是你修改代码的时候。
实践一个单元测试
场景
遇到的一个业务场景是数个APP上的链接拼接规则不同，通过一些函数规范输出成拼接好的字符串。实现拼接功能本身并不麻烦，麻烦的是各个APP链接规则不同，在迭代（比如添加日志参数、新增支持的APP）等功能时非常容易出错，因此接入单测，提高效率。
项目是一个用vue-cli进行的初始化，是为了给上述功能提供简单的web页面，因此UI部分不是重点，暂时不接入单测，只对纯js的逻辑部分接入单测。
使用
jest非常易于使用，文档也很详细，这里主要说一下我在项目里的应用步骤
安装jest。官方文档中大多数使用yarn（另一种包管理工具）命令，不过使用npm也是可行的。
npm install --save-dev jest修改package.json添加如下命令（–coverage表示打印覆盖率等信息）
{
"script": {
"test": "jest --coverage"
}
}项目根目录下建立tests文件夹（和src目录平级），里面建立和要测试的文件同路径的测试文件，命名为xxx.test.js
引入要添加单测的函数
编写单测
- 在expect中调用引入的函数，通过匹配器（有用于数字、对象、字符串等多种不同匹配器）判断输出是否符合预期
- 可mock一些考虑边界情况、异常输入等的测试用例
test('two plus two is four', () => {
expect(2 + 2).toBe(4);
});
- 修改package.json文件，在pre-commit的钩子也执行，这样其它人修改这个项目提交也会默认走一次单测
- 也可以通过npm run test手动执行单测
FAQ
- 我有代码规范检查，test函数为全局方法，会报未定义的错误？
- 答：通过 /* global test */ 注释将test函数标记为全局变量即可
- 上面说了纯js的测试方案，那么单文件组件（含有UI、生命周期等）该如何测试？
- 答：本质上思路是一样的，就是看在指定输入下输出是否符合预期。UI测试用例的编写可能要麻烦一些，网上能找到很多资料，这里不再赘述。