前言

恰好在公司一个项目中需要配置单元测试,借着机会学习了一下。经过对比最终选用了Facebook的jest测试框架,本文包含以下几点内容

  1. 什么是单元测试?
  2. 什么时候使用单元测试?
  3. 如何使用单元测试?

什么是单元测试(Unit Testing)?

什么是单元?软件设计的最小单位。在过程化编程时,它可以是单个程序、函数、过程等;在面向对象的编程中,它可以是方法,包括基类、抽象类、子类中的方法等。 所谓单元测试,就是针对软件设计的最小单位来进行正确性检验的测试工作。 除了单元测试之外,还有集成测试、系统测试、验收测试等测试类型,它们作用在项目开发的不同阶段,测试目的也不尽相同。

什么时候使用单元测试?

软件设计有两个终极目标:

  1. 实现需求;
  2. 代码质量及可维护性。

所以要判断什么时候使用单元测试,就是看是否实现了这两个目标。举例说明,考虑如下两个场景:

  1. 输出Hello World,几行代码;
  2. 某公司的管理系统,2w+代码,上千个函数及方法。

对于场景1,需求简单,无论是代码质量,还是可维护性,都相当高,这样的场景显然没有必要添加单元测试。对于场景2,你能保证组成这个系统的上千个函数和方法没有BUG吗?即使你天赋异禀,能够让如此复杂的代码不失控,那么遇到需求迭代工作交接等场景时,能保证变更不引入新的问题么?(稍有工程经验的人应该都体会过一边修bug一边写bug的绝望)

所以我们的结论是,如果你的场景需求简单、个人开发、代码量小,或者你是准备干一票跑路,那么单测也许显得不那么重要。但是如果系统的复杂度终究会超过个人的精力,那么你需要单元测试这样的工具帮助你规避潜在的风险。最能体现单元测试意义的场景,就是你修改代码的时候。

实践一个单元测试

场景

遇到的一个业务场景是数个APP上的链接拼接规则不同,通过一些函数规范输出成拼接好的字符串。实现拼接功能本身并不麻烦,麻烦的是各个APP链接规则不同,在迭代(比如添加日志参数、新增支持的APP)等功能时非常容易出错,因此接入单测,提高效率。

项目是一个用vue-cli进行的初始化,是为了给上述功能提供简单的web页面,因此UI部分不是重点,暂时不接入单测,只对纯js的逻辑部分接入单测。

使用

jest非常易于使用,文档也很详细,这里主要说一下我在项目里的应用步骤,具体的API调用可以直接参考官方文档 Getting Started

  1. 安装jest。官方文档中大多数使用yarn(另一种包管理工具)命令,不过使用npm也是可行的。
npm install --save-dev jest
  1. 修改package.json添加如下命令(–coverage表示打印覆盖率等信息)
{
    "script": {
        "test": "jest --coverage"
    }
}
  1. 项目根目录下建立tests文件夹(和src目录平级),里面建立和要测试的文件同路径的测试文件,命名为xxx.test.js
  2. 引入要添加单测的函数
  3. 编写单测
    • 在expect中调用引入的函数,通过匹配器(有用于数字、对象、字符串等多种不同匹配器)判断输出是否符合预期
    • 可mock一些考虑边界情况、异常输入等的测试用例
test('two plus two is four', () => {
  expect(2 + 2).toBe(4);
});
  1. 修改package.json文件,在pre-commit的钩子也执行,这样其它人修改这个项目提交也会默认走一次单测
  2. 也可以通过npm run test手动执行单测

FAQ

1. 我有代码规范检查,test函数为全局方法,会报未定义的错误?

答:通过 /* global test */ 注释将test函数标记为全局变量即可

2. 上面说了纯js的测试方案,那么单文件组件(含有UI、生命周期等)该如何测试?

答:本质上思路是一样的,就是看在指定输入下输出是否符合预期。UI测试用例的编写可能要麻烦一些,网上能找到很多资料,这里不再赘述。

参考链接

JavaScript单元测试