作为一个以 文档丰富 而广为人知的前端开发框架, Vue.js 的官方文档中分别在《教程-工具-单元测试》、《Cookbook-Vue组件的单元测试》里对 Vue 组件的单元测试方法做出了介绍,并提供了官方的单元测试实用工具库 Vue Test Utils;甚至在状态管理工具 Vuex 的文档里也不忘留出《测试》一章。
那是什么原因让 Vue.js 的开发团队如此重视单元测试,要在这个同样以 易于上手 为卖点的框架中大力科普呢?
官方文档中给出了非常清楚的说法:
组件的单元测试有很多好处:
- 提供描述组件行为的文档
- 节省手动测试的时间
- 减少研发新特性时产生的 bug
- 改进设计
- 促进重构
自动化测试使得大团队中的开发者可以维护复杂的基础代码。
本文作为《对 React 组件进行单元测试》一文的姊妹篇,将照猫画虎式的尝试面对初学和向中级进阶的开发者,对单元测试在 Vue.js 技术栈 中的应用做出入门介绍。
I. 单元测试简介
单元测试(unit testing),是指对软件中的最小可测试单元进行检查和验证。
简单来说,单元
就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
对于开发活动中的各种测试,上图是一种最常见的划分方法:从下至上依次为 单元测试->集成测试->端到端测试 ,随着其集成度的递增,对应的自动化程度递减。
端到端(在浏览器等真实场景中走通功能而把程序当成黑盒子的测试)与集成测试(集合多个测试过的单元一起测试)的反馈与修复的周期比较长、运行速度慢,测试运行不稳定,由于很多时候还要靠人工手动进行,维护成本也很高。而单元测试只针对具体一个方法或API,定位准确,采用 mock 机制,运行速度非常快(毫秒级),又是开发人员在本地执行,反馈修复及时,成本较低。
我们把绝大部分能在单元测试里覆盖的用例都放在单元测试覆盖,只有单元测试测不了的,才会通过端到端与集成测试来覆盖。
讲解单元测试的具体概念之前,先 咀个栗子 直观了解下:
比如我们有这样一个模块,暴露两个方法用以对菜单路径进行一些处理:
// src/menuChecker.js
export function getRoutePath(str) {
let to = ""
//...
return to;
}
export function getHighlight(str) {
let hl = "";
//...
return hl;
}
编写对应的测试文件:
import {
getRoutePath,
getHighlight
} from "@/menuChecker";
describe("检查菜单路径相关函数", ()=>{
it("应该获得正确高亮值", ()=>{
expect( getHighlight("/myworksheet/(.*)") ).toBe("myTickets");
});
it("应该为未知路径取得默认的高亮值", ()=>{
expect( getHighlight("/myworksheet/ccc/aaa") ).toBe("mydefaulthl111");
});
it("应该补齐开头的斜杠", ()=>{
expect( getRoutePath("/worksheet/list") ).toBe('/worksheet/list');
});
it("应该能修正非法的路径", ()=>{
expect( getRoutePath("/myworksheet/(.*)") ).toBe("/myworksheet/list");
});
});
运行该测试文件,得到如下输出:

运行结果可以说非常友好了,虽然醒目的提示了 FAIL,但是哪条判断错了、错在哪一行、实际的返回值与预期的区别,甚至代码覆盖率的表格,都分别展示了出来;尤其是最重要的对错结果,分别用绿色红色加以展示。
真相只有一个,要么是目标模块写的有问题,要么是测试条件写错了 -- 总之我们对其修正后重新运行:
由此,我们对一次单元测试的过程有了基本的了解。
首先,对所谓“单元”的定义是灵活的,可以是一个函数,可以是一个模块,也可以是一个 Vue Component。
其次,由于测试结果中,成功的用例会用绿色表示,而失败的部分会显示为红色,所以单元测试也常常被称为 “Red/Green Testing” 或 “Red/Green Refactoring”,其一般步骤可以归纳为:
- 添加一个测试
- 运行所有测试,看看新加的这个测试是不是失败了;如果能成功则重复步骤1
- 根据失败报错,有针对性的编写或改写代码;这一步的唯一目的就是通过测试,先不必纠结细节
- 再次运行测试;如果能成功则跳到步骤5,否则重复步骤3
- 重构已经通过测试的代码,使其更可读、更易维护,且不影响通过测试
- 重复步骤1,直到所有功能测试完毕
1.1 测试框架
测试框架的作用是提供一些方便的语法来描述测试用例,以及对用例进行分组。
1.2 断言(assertions)
断言是单元测试框架中核心的部分,断言失败会导致测试不通过,或报告错误信息。
对于常见的断言,举一些例子如下:
-
同等性断言 Equality Asserts
- expect(sth).toEqual(value)
- expect(sth).not.toEqual(value)
-
比较性断言 Comparison Asserts
- expect(sth).toBeGreaterThan(number)
- expect(sth).toBeLessThanOrEqual(number)
-
类型性断言 Type Asserts
- expect(sth).toBeInstanceOf(Class)
-
条件性测试 Condition Test
- expect(sth).toBeTruthy()
- expect(sth).toBeFalsy()
- expect(sth).toBeDefined()
1.3 断言库
断言库主要提供上述断言的语义化方法,用于对参与测试的值做各种各样的判断。这些语义化方法会返回测试的结果,要么成功、要么失败。常见的断言库有 Should.js, Chai.js 等。
1.4 测试用例 test case
为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。
一般的形式为:
it('should ...', function() {
...
expect(sth).toEqual(sth);
});
1.5 测试套件 test suite
通常把一组相关的测试称为一个测试套件
一般的形式为:
describe('test ...', function() {
it('should ...', function() { ... });
it('should ...', function() { ... });
...
});
1.6 spy
正如
spy
字面的意思一样,我们用这种“间谍”来“监视”函数的调用情况
通过对监视的函数进行包装,可以通过它清楚的知道该函数被调用过几次、传入什么参数、返回什么结果,甚至是抛出的异常情况。
var spy = sinon.spy(MyComp.prototype, 'someMethod');
...
expect(spy.callCount).toEqual(1);
1.7 stub
有时候会使用
stub
来嵌入或者直接替换掉一些代码,来达到隔离的目的
一个stub
可以使用最少的依赖方法来模拟该单元测试。比如一个方法可能依赖另一个方法的执行,而后者对我们来说是透明的。好的做法是使用stub 对它进行隔离替换。这样就实现了更准确的单元测试。
var myObj = {
prop: function() {
return 'foo';
}
};
sinon.stub(myObj, 'prop').callsFake(function() {
return 'bar';
});
myObj.prop(); // 'bar'
1.8 mock
mock
一般指在测试过程中,对于某些不容易构造或者不容易获取的对象,用一个虚拟的对象来创建以便测试的测试方法
广义的讲,以上的 spy 和 stub 等,以及一些对模块的模拟,对 ajax 返回值的模拟、对 timer 的模拟,都叫做 mock 。
1.9 测试覆盖率(code coverage)
用于统计测试用例对代码的测试情况,生成相应的报表,比如 istanbul
是常见的测试覆盖率统计工具。
istanbul
也就是土耳其首都 “伊斯坦布尔”,这样命名是因为土耳其地毯世界闻名,而地毯是用来"覆盖"的😷。
回顾一下上面的图:
表格中的第2列至第5列,分别对应了四个衡量维度:
- 语句覆盖率(statement coverage):是否每个语句都执行了
- 分支覆盖率(branch coverage):是否每个
if
代码块都执行了 - 函数覆盖率(function coverage):是否每个函数都调用了
- 行覆盖率(line coverage):是否每一行都执行了
测试结果根据覆盖率被分为“绿色、黄色、红色”三种,应该关注这些指标,测试越全面,就能提供更高的保证。
同时也没有必要一味追求行覆盖率,因为它会导致我们过分关注组件的内部实现细节,从而导致琐碎的测试。
II. Vue.js 中的单元测试工具
2.1 Jest

不同于"传统的"(其实也没出现几年)的 jasmine / Mocha / Chai 等前端测试框架;Jest
的使用更简单(也许就是这个单词的本意“俏皮话、玩笑话”的意思),并且提供了更高的集成度、更丰富的功能。
Jest 是一个由 Facebook 开发的测试运行器,相对其他测试框架,其特点就是就是内置了常用的测试工具,比如自带断言、测试覆盖率工具,实现了开箱即用。
此外, Jest 的测试用例是并行执行的,而且只执行发生改变的文件所对应的测试,提升了测试速度。
配置
Jest 号称自己是一个 “Zero configuration testing platform”,只需在 npm scripts
里面配置了test: jest
,即可运行npm test
,自动识别并测试符合其规则的( Vue.js 项目中一般是 __tests__
目录下的)用例文件。
实际使用中,适当的在 package.json 的 jest 字段或独立的 jest.config.js 里自定义配置一下,会得到更适合我们的测试场景。
参考文档 vue-test-utils.vuejs.org/zh/guides/t… ,可以很快在 Vue.js 项目中配置好 Jest 测试环境。
四个基础单词
编写单元测试的语法通常非常简单;对于jest
来说,由于其内部使用了 Jasmine 2
来进行测试,故其用例语法与 Jasmine 相同。
实际上,只要先记这住四个单词,就足以应付大多数测试情况了:
describe
: 定义一个测试套件it
:定义一个测试用例expect
:断言的判断条件toEqual
:断言的比较结果
describe('test ...', function() {
it('should ...', function() {
expect(sth).toEqual(sth);
expect(sth.length).toEqual(1);
expect(sth > oth).toEqual(true);
});
});
2.2 sinon

图中这位“我牵着马”的并不是卷帘大将沙悟净...其实图中的故事正是人所皆知的“特洛伊木马”;大概意思就是希腊人围困了特洛伊人十多年,久攻不下,心生一计,把营盘都撤了,只留下一个巨大的木马(里面装着士兵),以及这位被扒光还被打得够呛的人,也就是此处要谈的主角 sinon,由他欺骗特洛伊人 --- 后面的剧情大家就都熟悉了。
所以这个命名的测试工具呢,也正是各种伪装渗透方法的合集,为单元测试提供了独立而丰富的 spy, stub 和 mock 方法,兼容各种测试框架。
虽然 Jest 本身也有一些实现 spy 等的手段,但 sinon 使用起来更加方便。
2.3 Vue Test Utils
Vue Test Utils 是 Vue.js 官方的单元测试实用工具库;该工具库使用起来和用以测试 React 组件的 Enzyme 工具库非常相似
它模拟了一部分类似 jQuery 的 API,非常直观并且易于使用和学习,提供了一些接口和几个方法来减少测试的样板代码,方便判断、操纵和遍历 Vue Component 的输出,并且减少了测试代码和实现代码之间的耦合。
一般使用其 mount()
或 shallowMount()
方法,将目标组件转化为一个 Wrapper
对象,并在测试中调用其各种方法,例如:
import { mount } from '@vue/test-utils'
import Foo from './Foo.vue'
describe('Foo', () => {
it('renders a div', () => {
const wrapper = mount(Foo)
expect(wrapper.contains('div')).toBe(true)
})
})
III. 一个 Vue.js 的单元测试实例
3.1 又一个栗子
import { shallowMount } from "@vue/test-utils";
import Vue from 'vue';
import VueI18n from 'vue-i18n';
import i18nMessage from '@/i18n';
import Comp from "@/components/Device.vue";
const fakeData = { //假数据
deviceNo: "abcdefg",
deviceSpace: 45,
deviceStatus: 2,
devices: [
{
id: "test001",
location: "12",
status: 1
},
{
id: "test002",
location: "58",
status: 3
},
{
id: "test003",
location: "199",
status: 4
}
]
};
Vue.use(VueI18n); //重现必要的依赖
const i18n = new VueI18n({
locale: 'zh-CN',
silentTranslationWarn: true,
missing: (locale, key, vm) => key,
messages: i18nMessage
});
let wrapper = null;
const makeWrapper = ()=>{
wrapper = shallowMount( Comp, {
i18n, //看这里
propsData: { //还有这里
unitHeight: 5,
data: fakeData
}
} );
};
afterEach(()=>{ //也很常见的用法
if (!wrapper) return;
wrapper = null;
});
describe("test Device.vue", ()=>{
it("should be a VUE instance", ()=>{
makeWrapper();
expect( wrapper.isVueInstance() ).toBeTruthy();
});
it("应该有正常的总高度", ()=>{
makeWrapper();
expect( wrapper.vm.totalHeight ).toBe( 1230 );
});
it("应该渲染正确的设备数量", ()=>{
makeWrapper();
expect( wrapper.findAll('.deviceitem').length ).toBe( 3 );
});
it("指定的设备应该在正确的位置", ()=>{
makeWrapper();
const sty = wrapper.findAll('.deviceitem').at(1).attributes('style');
expect( sty ).toMatch( /height\:\s*20px/ );
expect( sty ).toMatch( /bottom\:\s*20px/ );
});
it("应该渲染正确的tooltip", ()=>{
makeWrapper();
//这里的用法值得注意
const popper_ref = wrapper.find({ref: 'device_tooltip_test002'});
expect( popper_ref.exists() ).toBeTruthy();
const cont = popper_ref.find('.tooltip_cont');
expect( cont.html() ).toMatch(/所在位置\:\s58/);
});
it("应该渲染正确的设备分类", ()=>{
makeWrapper();
const badge = wrapper.find('.badge');
expect( badge.exists() ).toBeTruthy();
expect( badge.findAll('li').length ).toBe(4);
expect( badge.findAll('li').at(2).text() ).toBe('喷雾设备');
});
it("当点击了关闭按钮,应该不再显示", (done)=>{ //异步的用例
makeWrapper();
wrapper.vm.$nextTick(()=>{ //再看这里
expect(
wrapper.find('.devices_container').exists()
).toBeFalsy();
done();
});
});
});
这里无需逐条的解释,主要的 API 在 Jest
和 Vue Test Utils
的文档里都能找到。
其中值得注意的小经验,一是一些异步更新(比如代码中有延时)后正确使用 wrapper.vm.$nextTick
;二是对于一些挂载到 document.body 等外部位置的组件元素,要靠 wrapper.find({ref: xxx})
取得其引用。
3.2 整合到工作流中
写好的单元测试,如果仅仅要靠每次 npm test
手动执行,必然会有日久忘记、逐渐过时,最后甚至无法执行的情况。
有多个时间点可以作为选择,插入自动执行单元测试 -- 例如每次保存文件、每次执行 build 等;此处我们选择了一种很简单的配置办法:
首先在项目中安装 pre-commit
依赖包;然后在 package.json
中配置 npm scripts :
"scripts": {
...
"test": "jest"
},
"pre-commit": [
"test"
],
这样在每次 git commit
之前,项目中存在的单元测试就会自动执行一次,往往就避免了 “改一个 bug,送十个新 bug” 的窘况。
IV. 用单元测试改善 Vue.js 组件
单元测试除了减少错误,另一个显著的好处是能让我们组件化的思路越来越清晰,养成日益良好的习惯。
一个被验证过针对给定的输入会渲染出符合期望的输出的组件,称为 测试通过的 组件;
一个 可测试的(testable) 组件意味着其易于测试
如何确保一个组件如期望的工作呢?
我们可能习惯于依靠双手和眼睛,一次次的验证我们写过的组件;但如果你打算对每个组件的每个改动都手动验证的话,或早或晚就会因为疲惫或懈怠,导致瑕疵留在代码中。
这就是自动化的单元测试为何重要的原因。单元测试保证了每次对组件做出的更改后,组件都能正确工作。
单元测试并不只与早期发现 bug 有关。另一个重要的方面是用其检验组件架构化水平优劣的能力。
一个 无法测试 或 难以测试 的组件,基本上就等同于 设计得很拙劣 的组件.
组件之所以难以测试,是因为其有太多的 props、依赖、引用的模型和对全局变量的访问 -- 这都是不良设计的标志。
一个设计不佳的组件,就会变成无法测试的,进而你就会简单的跳过单元测试,又导致了其保持未测试状态,变成一个恶性循环。
4.1 希望是最后一个栗子
假设要对 NumStepper.vue 组件进行测试
//NumStepper.vue
<template>
<div>
<button class="plus" v-on:click="updateNumber(+1)">加</button>
<button class="minus" v-on:click="updateNumber(-1)">减</button>
<button class="zero" v-on:click="clear">清</button>
</div>
</template>
<script>
export default {
props: {
targetData: Object,
clear: Function
},
methods: {
updateNumber: function(n) {
this.targetData.num += n;
}
}
}
</script>
该组件又依赖一个外层组件给其提供数据和方法:
//NumberDisplay.vue
<template>
<div>
<p>{{somedata.num}}</p>
<NumStepper :targetData="somedata" :clear="clear" />
</div>
</template>
<script>
import NumStepper from "./NumStepper"
export default {
components: {
NumStepper
},
data() {
return {
somedata: {
num: 999
},
tgt: this
}
},
methods: {
clear: function() {
this.somedata.num = 0;
}
}
}
</script>
这样一来,我们的测试就得这样写:
import { shallowMount } from "@vue/test-utils";
import Vue from 'vue';
import NumStepper from '@/components/NumStepper';
import NumberDisplay from '@/components/NumberDisplay';
describe("测试 NumStepper 组件", ()=>{
it("应该能够影响外层组件的数据", ()=>{
const display = shallowMount(NumberDisplay);
const wrapper = shallowMount(NumStepper, {
propsData: {
targetData: display.vm.somedata,
clear: display.vm.clear
}
});
expect(display.vm.somedata.num).toBe(999);
wrapper.find('.plus').trigger('click');
wrapper.find('.plus').trigger('click');
expect(display.vm.somedata.num).toBe(1001);
wrapper.find('.minus').trigger('click');
expect(display.vm.somedata.num).toBe(1000);
wrapper.find('.zero').trigger('click');
expect(display.vm.somedata.num).toBe(0);
})
});
<NumStepper>
测试起来非常复杂,因为它关联了外部组件的实现细节。
测试场景中需要一个额外的 <NumberDisplay>
组件,用来重现外部组件、向目标组件传递数据和方法,并检验目标组件是否正确修改了外部组件的状态。
不难想象,假如 <NumberDisplay>
组件再依赖其他组件或环境变量、全局方法等,事情将变得更糟糕,可能需要单独实现若干测试专用组件,甚至根本无法测试。
4.2 真正的最后一个栗子
当 <NumStepper>
独立于外部组件的细节时,测试就简单了。让我们实现并测试一下合理封装版本的 <NumStepper>
组件:
//NumStepper2.vue
<template>
<div>
<button class="plus" v-on:click="updateFunc(+1)">加</button>
<button class="minus" v-on:click="updateFunc(-1)">减</button>
<button class="zero" v-on:click="clearFunc">清</button>
</div>
</template>
<script>
export default {
props: {
updateFunc: Function,
clearFunc: Function
}
}
</script>
在测试中,就不用引入额外的组件了:
import { shallowMount } from "@vue/test-utils";
import Vue from 'vue';
import NumStepper from '@/components/NumStepper2';
describe("测试 NumStepper 组件", ()=>{
it("应该能够影响外层组件的数据", ()=>{
const obj = {
func1: function(){},
func2: function(){}
};
const spy1 = jest.spyOn(obj, "func1");
const spy2 = jest.spyOn(obj, "func2");
const wrapper = shallowMount(NumStepper, {
propsData: {
updateFunc: spy1,
clearFunc: spy2
}
});
wrapper.find('.plus').trigger('click');
expect(spy1).toHaveBeenCalled();
wrapper.find('.minus').trigger('click');
expect(spy1).toHaveBeenCalled();
wrapper.find('.zero').trigger('click');
expect(spy2).toHaveBeenCalled();
})
});
注:该示例中只是检验了是否被点击,还可以引入 sinon 的相关方法检验传入的参数等,写出更完备的测试。
V. 总结
单元测试作为一种经典的开发和重构手段,在软件开发领域被广泛认可和采用;前端领域也逐渐积累起了丰富的测试框架和方法。
单元测试可以为我们的开发和维护提供基础保障,使我们在思路清晰、心中有底的情况下完成对代码的搭建和重构。
封装好则测试易,反之不恰当的封装让测试变得困难。
可测试性是一个检验组件结构良好程度的实践标准。
VI. 参考资料
- juejin.cn/post/684490…
- juejin.cn/post/684490…
- blog.csdn.net/xqtesting/a…
- www.jianshu.com/p/ec40734c8…
- www.jianshu.com/p/ffd6d319f…