对 React 组件进行单元测试

前端开发的一个特点是更多的会涉及用户界面,当开发规模达到一定程度时,几乎注定了其复杂度会成倍的增长。

无论是在代码的初始搭建过程中,还是之后难以避免的重构和修正bug过程中,常常会陷入逻辑难以梳理、无法掌握全局关联的境地。

而单元测试作为一种“提纲挈领、保驾护航”的基础手段,为开发提供了“围墙和脚手架”,可以有效的改善这些问题。

作为一种经典的开发和重构手段,单元测试在软件开发领域被广泛认可和采用;前端领域也逐渐积累起了丰富的测试框架和最佳实践。

本文将按如下顺序进行说明:

I. 单元测试简介

II. React 单元测试中用到的工具

III. 用测试驱动 React 组件重构

IV. React 单元测试常见案例

I. 单元测试简介

单元测试(unit testing),是指对软件中的最小可测试单元进行检查和验证。

简单来说,就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

测试框架

测试框架的作用是提供一些方便的语法来描述测试用例,以及对用例进行分组。

断言(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()

断言库

断言库主要提供上述断言的语义化方法,用于对参与测试的值做各种各样的判断。这些语义化方法会返回测试的结果,要么成功、要么失败。常见的断言库有 Should.js, Chai.js 等。

测试用例 test case

为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。

一般的形式为:

测试套件 test suite

通常把一组相关的测试称为一个测试套件

一般的形式为:

spy

正如 字面的意思一样,我们用这种“间谍”来“监视”函数的调用情况

通过对监视的函数进行包装,可以通过它清楚的知道该函数被调用过几次、传入什么参数、返回什么结果,甚至是抛出的异常情况。

stub

有时候会使用来嵌入或者直接替换掉一些代码,来达到隔离的目的

一个可以使用最少的依赖方法来模拟该单元测试。比如一个方法可能依赖另一个方法的执行,而后者对我们来说是透明的。好的做法是使用stub 对它进行隔离替换。这样就实现了更准确的单元测试。

mock

一般指在测试过程中,对于某些不容易构造或者不容易获取的对象,用一个虚拟的对象来创建以便测试的测试方法

广义的讲,以上的 spy 和 stub 等,以及一些对模块的模拟,对 ajax 返回值的模拟、对 timer 的模拟,都叫做 mock 。

测试覆盖率(code coverage)

用于统计测试用例对代码的测试情况,生成相应的报表,比如 是常见的测试覆盖率统计工具

II. React 单元测试中用到的工具

Jest

不同于"传统的"(其实也没出现几年)的 jasmine / Mocha / Chai 等前端测试框架 -- 的使用更简单,并且提供了更高的集成度、更丰富的功能。

Jest 是 Facebook 出品的一个测试框架,相对其他测试框架,其一大特点就是就是内置了常用的测试工具,比如自带断言、测试覆盖率工具,实现了开箱即用。

此外, Jest 的测试用例是并行执行的,而且只执行发生改变的文件所对应的测试,提升了测试速度。

四个基础单词

编写单元测试的语法通常非常简单;对于来说,由于其内部使用了 来进行测试,故其用例语法与 Jasmine 相同。

实际上,只要先记这住四个单词,就足以应付大多数测试情况了:

: 定义一个测试套件

:定义一个测试用例

:断言的判断条件

:断言的比较结果

配置

Jest 号称自己是一个 “Zero configuration testing platform”,只需在 里面配置了,即可运行,自动识别并测试符合其规则的(一般是 目录下的)用例文件。

实际使用中,适当的自定义配置一下,会得到更适合我们的测试场景:

在这个简单的配置文件中,我们指定了测试的“根目录”,配置了覆盖率(内置的)的一些格式,并将原本在webpack中对样式文件的引用指向了一个空模块,从而跳过了这一对测试无伤大雅的环节

另外值得一提的是,由于是一个会在脚本中被调用的普通 JS 文件,而非或的形式,所以 nodejs 的各自操作都可以进行,比如引入 fs 进行预处理读写等,灵活性非常高,可以很好的兼容各种项目

babel-jest

由于是面向目录下测试其React代码,并且还使用了ES6语法,所以项目下需要存在一个文件:

以上是基本的配置,而实际由于webpack可以编译es6的模块,一般将babel中设为,此时的配置为:

Enzyme

Enzyme 来自于活跃在 JavaScript 开源社区的 Airbnb 公司,是对官方测试工具库(react-addons-test-utils)的封装。

这个单词的伦敦读音为 ,酵素或酶的意思,Airbnb 并没有给它设计一个图标,估计就是想取用它来分解 React 组件的意思吧。

它模拟了 jQuery 的 API,非常直观并且易于使用和学习,提供了一些与众不同的接口和几个方法来减少测试的样板代码,方便判断、操纵和遍历 React Components 的输出,并且减少了测试代码和实现代码之间的耦合。

一般使用 Enzyme 中的 或 方法,将目标组件转化为一个 对象,并在测试中调用其各种方法:

sinon

图中这位“我牵着马”的并不是卷帘大将沙悟净...其实图中的故事正是人所皆知的“特洛伊木马”;大概意思就是希腊人围困了特洛伊人十多年,久攻不下,心生一计,把营盘都撤了,只留下一个巨大的木马(里面装着士兵),以及这位被扒光还被打得够呛的人,也就是此处要谈的主角sinon,由他欺骗特洛伊人 --- 后面的剧情大家就都熟悉了。

所以这个命名的测试工具呢,也正是各种伪装渗透方法的合集,为单元测试提供了独立而丰富的 spy, stub 和 mock 方法,兼容各种测试框架。

虽然 Jest 本身也有一些实现 spy 等的手段,但 sinon 使用起来更加方便。

III. 用测试驱动 React 组件重构

这里不展开讨论经典的 “测试驱动开发”(TDD - test driven development) 理论 -- 简单的说,把测试正向加诸开发,先写用例再逐步实现,就是TDD,这是很好理解的。

而当我们反过头来,对既有代码补充测试用例,使其测试覆盖率不断提高,并在此过程中改善原有设计,修复潜在问题,同时又保证原有接口不收影响,这种 TDD 行为虽然没人称之为“测试驱动重构”(test driven refactoring),但“重构”这个概念本身就包含了用测试保驾护航的意思,是必不可少的题中之意。

对于一些组件和共有函数等,完善的测试也是一种最好的使用说明书。

失败-编码-通过 三部曲

由于测试结果中,成功的用例会用绿色表示,而失败的部分会显示为红色,所以单元测试也常常被称为 “Red/Green Testing” 或 “Red/Green Refactoring” , 这也是 TDD 中的一般性步骤:

添加一个测试

运行所有测试,看看新加的这个是不是失败了;如果能成功则重复步骤1

根据失败报错,有针对性的编写或改写代码;这一步的唯一目的就是通过测试,先不必纠结细节

再次运行测试;如果能成功则跳到步骤5,否则重复步骤3

重构已经通过测试的代码,使其更可读、更易维护,且不影响通过测试

重复步骤1

解读测试覆盖率

这就是 内置的 输出的覆盖率结果。

之所以叫做“伊斯坦布尔”,是因为土耳其地毯世界闻名,而地毯是用来"覆盖"的

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20180201G07RUQ00?refer=cp_1026

扫码关注云+社区