在Nodejs中贯彻单元测试

冷不防 2022-05-27 06:13 186阅读 0赞

来源： https://www.jianshu.com/p/3bcac18945a3

在团队合作中，你写好了一个函数，供队友使用，跑去跟你的队友说，你传个A值进去，他就会返回B结果了。过了一会，你队友跑过来说，我传个A值却返回C结果，怎么回事？你丫的有没有测试过啊？

大家一起写个项目，难免会有我要写的函数里面依赖别人的函数，但是这个函数到底值不值得信赖？单元测试是衡量代码质量的一重要标准，纵观Github的受欢迎项目，都是有test文件夹，并且buliding-pass的。如果你也为社区贡献过module，想更多人使用的话，加上单元测试吧，让你的module值得别人信赖。

要在Nodejs中写单元测试的话，你需要知道用什么测试框架，怎么测试异步函数，怎么测试私有方法，怎么模拟测试环境，怎么测试依赖HTTP协议的web应用，需要了解TDD和BDD，还有需要提供测试的覆盖率。

> 本文的示例代码会备份到 Github : [unittest-demo][]

## 目录 ##

1.  测试框架
2.  断言库
3.  需求变更
4.  异步测试
5.  异常测试
6.  测试私有方法
7.  测试Web应用
8.  覆盖率
9.  使用Makefile把测试串起来
10. 持续集成，Travis-cli
11. 一些观点
12. 彩蛋
13. 整理

## 测试框架 ##

Nodejs的测试框架还用说？大家都在用，Mocha。  
Mocha 是一个功能丰富的Javascript测试框架，它能运行在Node.js和浏览器中，支持**BDD**、**TDD**、**QUnit**、**Exports**式的测试，本文主要示例是使用更接近与思考方式的BDD，�如果了解更多可以访问Mocha的[官网][Link 1]

#### 测试接口 ####

Mocha的BDD接口有：

*  `describe()`
 *  `it()`
 *  `before()`
 *  `after()`
 *  `beforeEach()`
 *  `afterEach()`

#### 安装 ####

`npm install mocha -g`

#### 编写一个稳定可靠的模块 ####

模块具备limit方法，输入一个数值，小于0的时候返回0，其余正常返回

exports.limit = function (num) { if (num < 0) { return 0; } return num; };

#### 目录分配 ####

*  `lib`，存放模块代码的地方
 *  `test`，存放单元测试代码的地方
 *  `index.js`，向外导出模块的地方
 *  `package.json`，包描述文件

#### 测试 ####

var lib = require('index'); describe('module', function () { describe('limit', function () { it('limit should success', function () { lib.limit(10); }); }); });

#### 结果 ####

在当前目录下执行`mocha`：

$ mocha
    
      ․
    
      ✔ 1 test complete (2ms)

## 断言库 ##

上面的代码只是运行了代码，并没有对结果进行检查，这时候就要用到断言库了，Node.js中常用的断言库有：

*  should.js
 *  expect.js
 *  chai

#### 加上断言 ####

使用`should`库为测试用例加上断言

it('limit should success', function () { lib.limit(10).should.be.equal(10); });

## �需求变更 ##

需求变更啦： `limit`这个方法还要求返回值大于100时返回100。  
针对需求重构代码之后，正是测试用例的价值所在了，  
它能确保你的改动对原有成果没有造成破坏。  
但是，你要多做的一些工作的是，需要为新的需求编写新的测试代码。

## 异步测试 ##

#### 测试异步回调 ####

lib库中新增async函数：

exports.async = function (callback) { setTimeout(function () { callback(10); }, 10); };

测试异步代码：

describe('async', function () { it('async', function (done) { lib.async(function (result) { done(); }); }); });

#### 测试Promise ####

使用should提供的Promise断言接口:

*  `finally` | `eventually`
 *  `fulfilled`
 *  `fulfilledWith`
 *  `rejected`
 *  `rejectedWith`
 *  `then`

测试代码

describe('should', function () { describe('#Promise', function () { it('should.reject', function () { (new Promise(function (resolve, reject) { reject(new Error('wrong')); })).should.be.rejectedWith('wrong'); }); it('should.fulfilled', function () { (new Promise(function (resolve, reject) { resolve({ username: 'jc', age: 18, gender: 'male'}) })).should.be.fulfilled().then(function (it) { it.should.have.property('username', 'jc'); }) }); }); });

#### 异步方法的超时支持 ####

Mocha的超时设定默认是2s，如果执行的测试超过2s的话，就会报timeout错误。  
可以主动修改超时时间，有两种方法。

#### 命令行式 ####

`mocha -t 10000`

#### API式 ####

describe('async', function () { this.timeout(10000); it('async', function (done) { lib.async(function (result) { done(); }); }); });

这样的话`async`执行时间不超过10s，就不会报错timeout错误了。

## 异常测试 ##

异常应该怎么测试，现在有`getContent`方法，他会读取指定文件的内容，但是不一定会成功，会抛出异常。

exports.getContent = function (filename, callback) { fs.readFile(filename, 'utf-8', callback); };

这时候就应该模拟(mock)错误环境了

#### 简单Mock ####

describe("getContent", function () { var _readFile; before(function () { _readFile = fs.readFile; fs.readFile = function (filename, encoding, callback) { process.nextTick(function () { callback(new Error("mock readFile error")); }); }; }); // it(); after(function () { // 用完之后记得还原。否则影响其他case fs.readFile = _readFile; }) });

#### �Mock库 ####

Mock小模块：[`muk`][muk] ，略微优美的写法：

## 测试私有方法 ##

针对一些内部的方法，没有通过exports暴露出来，怎么测试它？

function _adding(num1, num2) { return num1 + num2; }

#### 通过rewire导出方法 ####

模块：[`rewire`][rewire]

it('limit should return success', function () { var lib = rewire('../lib/index.js'); var litmit = lib.__get__('limit'); litmit(10); });

## 测试Web应用 ##

在开发Web项目的时候，要测试某一个API，如：`/user`，到底怎么编写测试用例呢？

使用：[`supertest`][supertest]

## 覆盖率 ##

测试的时候，我们常常关心，是否所有代码都测试到了。

这个指标就叫做["代码覆盖率"][Link 2]（code coverage）。它有四个测量维度。

>  *  **行覆盖率**（line coverage）：是否每一行都执行了？
>  *  **函数覆盖率**（function coverage）：是否每个函数都调用了？
>  *  **分支覆盖率**（branch coverage）：是否每个if代码块都执行了？
>  *  **语句覆盖率**（statement coverage）：是否每个语句都执行了？

[Istanbul][] 是 JavaScript 程序的代码覆盖率工具。

#### 安装 ####

`$ npm install -g istanbul`

#### 覆盖率测试 ####

在编写过以上的测试用例之后，执行命令：

`istanbul cover _mocha`

就能得到覆盖率:

JerryC% istanbul cover _mocha module limit ✓ limit should success async ✓ async getContent ✓ getContent add ✓ add should #Promise ✓ should.reject ✓ should fulfilled 6 passing (32ms) ================== Coverage summary ====================== Statements : 100% ( 10/10 ) Branches : 100% ( 2/2 ) Functions : 100% ( 5/5 ) Lines : 100% ( 10/10 ) ==========================================================

这条命令同时还生成了一个 coverage 子目录，其中的 coverage.json 文件包含覆盖率的原始数据，coverage/lcov-report 是可以在浏览器打开的覆盖率报告，其中有详细信息，到底哪些代码没有覆盖到。

![Image 1][]

覆盖率html

上面命令中，`istanbul cover` 命令后面跟的是 `_mocha` 命令，前面的下划线是不能省略的。

因为，[mocha 和 \_mocha 是两个不同的命令][mocha _ _mocha]，前者会新建一个进程执行测试，而后者是在当前进程（即 istanbul 所在的进程）执行测试，只有这样， istanbul 才会捕捉到覆盖率数据。其他测试框架也是如此，必须在同一个进程执行测试。

如果要向 mocha 传入参数，可以写成下面的样子。

$ istanbul cover _mocha -- tests/test.sqrt.js -R spec

上面命令中，两根连词线后面的部分，都会被当作参数传入 Mocha 。如果不加那两根连词线，它们就会被当作 istanbul 的参数（参考链接[1][]，[2][]）。

## 使用Makefile串起项目 ##

TESTS = test/*.test.js
    REPORTER = spec
    TIMEOUT = 10000
    JSCOVERAGE = ./node_modules/jscover/bin/jscover
    
    test:
        @NODE_ENV=test ./node_modules/mocha/bin/mocha -R $(REPORTER) -t $(TIMEOUT) $(TESTS)
    
    test-cov: lib-cov
        @LIB_COV=1 $(MAKE) test REPORTER=dot
        @LIB_COV=1 $(MAKE) test REPORTER=html-cov > coverage.html
    
    lib-cov:
        @rm -rf ./lib-cov
        @$(JSCOVERAGE) lib lib-cov
    
    .PHONY: test test-cov lib-cov
    
    make test
    make test-cov

用项目自身的jscover和mocha，避免版本冲突和混乱

## 持续集成，Travis-cli ##

*  [Travis-ci][]
    
     *  绑定Github帐号
     *  在Github仓库的Admin打开Services hook
     *  打开Travis
     *  每次push将会hook触发执行`npm test`命令

注意：Travis会将未描述的项目当作Ruby项目。所以需要在根目录下加入`.travis.yml`文件。内容如下：

language: node_js
    node_js:
     - "0.12"

Travis-cli还会对项目颁发标签，

![/][68747470733a2f2f7365637572652e7472617669732d63692e6f72672f4a61636b736f6e5469616e2f626167706970652e706e67]

![/][68747470733a2f2f7365637572652e7472617669732d63692e6f72672f54424544502f64617461766a732e706e67]

如果项目通过所有测试，就会build-passing，  
如果项目没有通过所有测试，就会build-failing

## 一些观点 ##

实施单元测试的时候, 如果没有一份经过实践证明的详细规范, 很难掌握测试的 "度", 范围太小施展不开, 太大又侵犯 "别人的" 地盘. 上帝的归上帝, 凯撒的归凯撒, 给单元测试念念紧箍咒不见得是件坏事, 反而更有利于发挥单元测试的威力, 为代码重构和提高代码质量提供动力.  
这份文档来自 Geotechnical, 是一份非常难得的经验准则. 你完全可以以这份准则作为模板, 结合所在团队的经验, 整理出一份内部单元测试准则.

[单元测试准则][Link 3]

## 彩蛋 ##

最后，介绍一个库：[`faker`][faker]  
他是一个能伪造用户数据的库，包括用户常包含的属性：个人信息、头像、地址等等。  
是一个开发初期，模拟用户数据的绝佳好库。  
支持Node.js和浏览器端

![Image 1][]

生成用户

## 整理 ##

#### Nodejs的单元测试工具 ####

1.  测试框架 mocha
2.  断言库：should.js、expect.js、chai
3.  覆盖率：istanbul、jscover、blanket
4.  Mock库：muk
5.  测试私有方法：rewire
6.  Web测试：supertest
7.  持续集成：Travis-cli

作者：JC\_Huang  
链接：https://www.jianshu.com/p/3bcac18945a3  
來源：简书  
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

[unittest-demo]: https://link.jianshu.com?t=https://github.com/JerryC8080/unittest-demo
[Link 1]: https://link.jianshu.com?t=http://mochajs.org/
[muk]: https://link.jianshu.com?t=https://github.com/fent/node-muk
[rewire]: https://link.jianshu.com?t=http://jhnns.github.com/rewire/
[supertest]: https://link.jianshu.com?t=https://github.com/visionmedia/supertest
[Link 2]: https://link.jianshu.com?t=http://en.wikipedia.org/wiki/Code_coverage
[Istanbul]: https://link.jianshu.com?t=https://github.com/gotwarlost/istanbul
[Image 1]: 
[mocha _ _mocha]: https://link.jianshu.com?t=https://github.com/gotwarlost/istanbul/issues/44
[1]: https://link.jianshu.com?t=http://www.clock.co.uk/blog/npm-module-code-coverage-in-2-simple-steps
[2]: https://link.jianshu.com?t=http://www.vapidspace.com/coding/2014/10/29/code-coverage-metrics-with-mocha-and-istanbul/
[Travis-ci]: https://link.jianshu.com?t=https://travis-ci.org/
[68747470733a2f2f7365637572652e7472617669732d63692e6f72672f4a61636b736f6e5469616e2f626167706970652e706e67]: /images/20220527/174353a23ca1447e9673608d524732f1.png
[68747470733a2f2f7365637572652e7472617669732d63692e6f72672f54424544502f64617461766a732e706e67]: /images/20220527/6b8a0580ca304669ae651b1432a5beaf.png
[Link 3]: https://link.jianshu.com?t=https://github.com/yangyubo/zh-unit-testing-guidelines
[faker]: https://link.jianshu.com?t=https://github.com/Marak/Faker.js