8 Node.js 单元测试

8.1 单元测试

8.1.1 引子

对于一个程序员来说不仅要写代码，还要验证一下代码写得到底对不对，写单元测试就是一个通用且有效的解决方案。单元测试很重要，可以将错误扼杀在摇篮中，如果你认为没有写单元测试也过得很好，也许等我介绍完 mocha 之后，你会改变主意的。下面给出一个栗子，假设有一个计算器的项目，不过这个项目周期比较长，后期需要增加更多的人手，所以对于每一个模块都要有相应的测试用例。下面是程序员小明开工后写的第一个函数，一个加法函数：

  1. function add(a,b) {
  2.     return a+b;
  3. }

代码 8.1.1.1 add函数如果你之前没有接触过单元测试，可能写出的测试用例是这样的：

  1. var s = add(1,2);
  2. if (s == 3) {
  3.     console.log('恭喜你，加法测试成功了');
  4. } else {
  5.     console.error('哎呦，加法测试出错了啊');
  6. }

代码 8.1.1.2 不使用测试框架的测试用例接着又需要写减法函数、乘法函数、除法函数，但是随着模块的增加，就会遇到一个问题，如果按照代码8.1.2的模式的话，一则输出格式比较乱，二则缺失测试结果统计。这时候大名鼎鼎的 mocha 就要闪亮登场了。有了 mocha ,测试结果输出格式化和测试结果统计的需求就可以迎刃而解了。比如说对于上面那个加法测试用例，就可以这么写了：

  1. var assert = require('assert');
  2. describe('Calculator', function() {
  3.   describe('#add()', function() {
  4.     it('should get 3 when 1 add 2', function() {
  5.       assert.equal(3, add(1,2));
  6.     });
  7.   });
  8. });

代码 8.1.3 使用mocha改写测试用例

mocha 在使用的时候，可以选择全局安装的模式，也可以安装为当前项目的开发依赖包（即在安装的时候使用--save-dev参数），不过每个项目中使用的版本可能会略有差异，并且部分 IDE 对于全局安装的支持并不是很好，所以推荐安装为当前项目的开发依赖。

我们将加法运算的代码封装在 calculator.js 中，并且提供一个 mocha 的测试文件 calculator_test.js: 

  1. var assert = require('assert');
  2. var calculator = require('./calculator');
  4. describe('Calculator', function() {
  5.   describe('#add()', function() {
  6.     it('should get 3 when 1 add 2', function() {
  7.       assert.equal(3, calculator.add(1,2));
  8.     });
  9.   });
  10. });

代码 8.1.4 文件calculator_test.js部分代码接着运行node calculator_test.js，不出意外会报错：

  1. e:\kuaipan\code\node\myapp\chapter7\src\test\mocha>node calculator_test.js 
  2. e:\kuaipan\code\node\myapp\chapter7\src\test\mocha\calculator_test.js:4   
  3. describe('Calculator', function() {     
  4. ^                             
  5. ReferenceError: describe is not defined  
  6.     at Object.<anonymous> (e:\kuaipan\code\node\myapp\chapter7\src\test\mocha\calculator_test.js:4:1)  
  7.     at Module._compile (module.js:456:26)           
  8.     at Object.Module._extensions..js (module.js:474:10)     
  9.     at Module.load (module.js:356:32)           
  10.     at Function.Module._load (module.js:312:12)  
  11.     at Function.Module.runMain (module.js:497:10)  
  12.     at startup (node.js:119:16)     
  13.     at node.js:929:3

输出 8.1.1.1 命令 node calculator_test.js 的输出这是由于函数 describe 只有通过 mocha 命令运行时才存在，换成使用 mocha calculator_test.js 来运行则能看到正确结构：

  1. e:\kuaipan\code\node\myapp\chapter7\src\test\mocha>mocha calculator_test.js                                
  2.   Calculator                 
  3.     #add()                    
  4.       √ should get 3 when 1 add 2  
  6.   1 passing (7ms)

输出 8.1.1.2 命令 mocha calculator_test.js 的输出

8.1.2 断言

这里之所以使用 node 自带的 assert 包，是由于 mocha 仅仅是一个测试框架，本身并没有提供断言（Assertion）库。很多第三方的断言库都可以和 mocha 完美结合：1.should.js他使用的格式是 (something).should 或者 should(something)，更多使用方法还得参阅其 github文档 ，例如上面我们使用 assert 进行判断的代码就可以写成:

  1. var should = require('should');
  3. (calculator.add(1,2)).should.be.exactly(3).and.be.a.Number();

代码 8.1.2.1 should判断1或者： 

  1. var should = require('should/as-function');
  3. should(calculator.add(1,2)).be.exactly(3).and.be.a.Number();

代码 8.1.2.2 should判断2

上面仅仅是简单说明使用方法，完整的测试用例大家可以参见第七章源码test/mocha/calculator_should1.js 和 test/mocha/calculator_should2.js。

2.expect.js首先给出expect.js的 github地址 ，下面是用expect重写的测试用例： 

  1. var expect = require('expect.js');
  2. expect(calculator.add(1,2)).to.be(3);

代码 8.1.2.3 expect判断3.chaichai 将前面提到的assert should expect融合到了一起，你仅仅需要使用 chai 这一个包就能享用以上三者的功能，所以前面讲到的三种判断在chai中是这么实现的： 

  1. var chai = require('chai');
  3. var assert = chai.assert;//use assert
  4. assert.equal(3, calculator.add(1,2));
  6. chai.should();//use should
  7. (calculator.add(1,2)).should.be.equal(3).and.be.a('number');
  9. var expect = chai.expect;//use expect
  10. expect(calculator.add(1,2)).to.equal(3);

代码 8.1.2.4 使用chai判断这个 chai 还真是个大杀器呢。不过注意，在 chai 中下面关键字

  1. to be been is that which and has have with at of same

只能作为属性使用，不能作为函数使用（除非你自己写代码把这些属性覆盖掉），所以 to.be(3) 要写作to.equal(3)，另外 chai 中也没有 exactly 这个函数，所以这里也是用 equal 来替代，同时在 chai 中 a 只能作为函数使用，其函数声明为 a(type) ,所以这里用了 a('number')，其他技术细节，请移步官方API BDD部分。

8.1.3 HTTP 测试

上面演示的是对程序本地调用的测试，不过很多情况下，我门的 API 是通过 HTTP 的形式对外提供访问的，比如说我们将上面提到的计算器的功能改为使用 HTTP 方式对外提供访问，这样的项目依然可以给出测试用例。HTTP请求和本地调用从流程是有很多不一样的地方的：当中隔着一个网络层，请求数据以 HTTP 报文的格式在网络上进行传输，服务器端解析 HTTP 报文内容后再调用本地 API 进行处理，然后再将处理结果通过 HTTP 报文返回给调用者。supertest 这个工具可以很好得在 mocha 中处理 HTTP 请求断言。

下面是一个 HTTP 接口：

  1. exports.doAdd = function(req, res) {
  2.     var _body = req.body;
  3.     var a = parseInt(_body.a, 10);
  4.     if (isNaN(a)) {
  5.         return res.send({code:1,msg:'a值非法'});
  6.     }
  7.     var b = parseInt(_body.b, 10);
  8.     if (isNaN(b)) {
  9.         return res.send({code:2,msg:'b值非法'});
  10.     }
  11.     res.send({code:0,data:a+b});
  12. };

代码 8.1.3.1 加法运算的 HTTP 接口

对应的supertest的测试用例代码就是这样的：

  1. var request = require('supertest');
  2. var app = require('../../app');
  4. describe('POST /calculator/add', function() {
  5.   it('respond with json', function(done) {
  6.     request(app)
  7.       .post('/calculator/add')
  8.       .send({a: 1,b:2})
  9.       .expect(200, {
  10.           code:0,data:3
  11.       },done);
  12.   });
  13. });

代码 8.1.3.2 加法运算HTTP接口的单元测试代码

此代码放置于第七章代码的目录 /src/test/http目录下，变量app其实是引用的项目根目录的app.js。

对于一个普通的网站来说，它的接口在访问之前，一定是经过授权的，否则就会将整个网站置于危险之中。用户名、密码登陆是我们常见的一种授权模式，为了简化我们的教程，我们姑且将 代码7.1.3 作为我们的登陆处理代码，那么登陆链接即为/user/login，管理后台首页为/user/admin。我们现在来测试登录到后台这个动作。

登录过程要牵扯到我们在第 6 章讲过的session的知识，但是 session 在前端对应的 sessionid 会写入 cookie 中，鉴于我们的测试运行环境是命令行，不是浏览器，这就需要我们自己来维护 cookie 的存储操作。同时我们还需要用到 mocha 中的钩子（Hook）函数，在这里用到的是 mocha 中的 before 函数，它表示在所有测试用例之前执行，当然还有 beforeEach 函数，它表示在每次测试用例执行前都执行一次。显然两者的区别是前者只在所有测试用例前执行一次，而后者要在每个测试用例执行前都要重新执行。先看这个钩子函数：

  1. var request = require('supertest');
  2. var app = require('../../app');
  3. var cookie = exports.cookie = '';
  5. before(function(done) {
  6.     request(app)
  7.       .post('/user/login')
  8.       .send({username:'admin', password:'admin'})
  9.       .expect(200,{code:0})
  10.       .end(function(err,res) {
  11.           if (err) {
  12.               return done(err);
  13.           }
  14.           var header = res.header;
  15.           var setCookieArray = header['set-cookie'];
  17.           for (var i=0,len=setCookieArray.length;i<len;i++) {
  18.               var value = setCookieArray[i];
  19.               var result = value.match(/^express_chapter7=([a-zA-Z0-9%\.\-_]+);\s/);
  20.               if (result && result.length > 1) {
  21.                   exports.cookie = cookie = result[1];
  22.                   break;
  23.               }
  24.           }
  25.           if (!cookie) {
  26.               return done(new Error('查找cookie失败'));
  27.           }
  28.           done();
  29.       });
  30. });

代码 8.1.3.3 钩子函数这里我们使用全局变量 cookie 来存储我们提到的 sessionid ，在 supertest 的 end 函数中，我们读取响应体变量res中的 set-cookie 头信息，通过正则把 sessionid 读取出来。注意我们这里将 cookie 这个变量还专门做导出了，这样子我们就可以在其他测试文件中引用这个变量了。接着就可以使用这个读取到的cookie来进入后台了： 

  1. var request = require('supertest');
  2. var app = require('../../app');
  3. var before = require('./login_before');
  5. describe('Backend',function() {
  7.     it('first test',function(done) {
  8.         request(app)
  9.         .get('/user/admin')
  10.         .set('Cookie','express_chapter7=' + before.cookie)
  11.         .expect(200,/<title>admin<\/title>/,done);
  12.     });
  13. });

代码 8.1.3.4 请求中使用cookie我们在模板 user/admin.ejs 有这么一句：<title><%=user.account%></title>，所以我们这里在测试时使用正则 /<title>admin<\/title>/ 来验证是否真的进入后台了。 还有就是在读取 cookie 变量的时候没有直接在 require 完成之后立即读取，因为那个时候，这个变量还没有被赋值，而是在测试用例内部通过 before.cookie 读取。

注意，由于我们使用了 redis 来存储 session 数据，所以如果你忘记启动 redis 服务器的话，我们的登录操作会失败，而且在 mocha 中给出的报错提示是请求超时，这个问题比较隐蔽，大家一定要注意。

8.2 测试覆盖率

我们写测试用例是为了及时发现开发中产生的 bug，这就引申出来一个问题，怎样写测试用例才能更好的将潜在的 bug 更好的暴漏出来，这也就是我们现在要讲的话题——测试覆盖率。

我们的测试代码是在源码的基础上编写的，那么它属于白盒测试，还有一种基于需求的测试，这种测试不接触源代码，属于黑盒测试。我们这一小节讲覆盖率，只讲白盒测试的覆盖率。

首先我们程序中有各种条件判断分支，理想的情况是，各个分支在测试用例中都有断言检测，但是实际情况中我们很难写出测试代码将所有分支都覆盖。将覆盖到的条件分支数 / 总的条件分支数，得到的比例数，是测试覆盖率的一种算法。为什么说一种呢？因为实际情况中，一个程序的执行是几个分支依次运行的，这些程序中执行的分支组合就形成一条条路径，所以说还有一种覆盖率的算法是 覆盖的测试路径 / 总的路径数。这种计算方法比较复杂，现在一些测试覆盖率的统计工具都是基于前者的，比如说我们下面要讲到的 nyc。

通过 npm 安装 nyc 后，修改 npm test 对应的命令，在 mocha 命令前添加一个 nyc 。比如说你之前的 npm run test 的命令是 mocha --recursive src/test/mocha --timeout 99999 --exit, 那么就可以改为 nyc mocha --recursive src/test/mocha --timeout 99999 --exit。同时新增一个 coverage 的 npm 命令：

"coverage": "nyc report --reporter=html"

之所以加一个 reporter 的参数，是因为默认的输出格式是文本格式的，可读性不强。

先后运行 npm run test 和 npm run coverage，打开项目更路径下的文件夹 coverage 下的 index.html，即可看到对于各个文件的测试分支覆盖情况。

测试覆盖率统计

图 8.2.1 测试覆盖率报告

最后说一下，在实践中的一些测试准测，由于覆盖率检测工具是基于分支的，所以即使覆盖率是 100%，依然无法保证所有的测试路径都会被涵盖到。并且当下的程序开发越来越依赖于团队协作，越来越倾向于往微服务的方向发展，单纯的一个服务 100% 没有问题，并不能保证整个系统是没有问题的。更有甚者，客户端存在的一些问题会倒逼服务器端去强行修改业务逻辑，保证线上业务的顺利进行。所有说，测试人员的集成测试还是至关重要的且无可替代的。

本章配套代码：https://github.com/yunnysunny/expressdemo/tree/master/chapter8