小明是一个前端工程师,近期因为个人兴趣以及工作上的需要,开始做 Node.js 相关的项目。一个多月过去了,小明基于 Koa 搭出了自己的第一个 Node.js web 应用,在这个过程中,小明也遇到了很多的问题:
- 如何在上线时保证代码完全没问题?
- 每次增加功能时如何保证之前的功能是可用的?
- 随着代码增多,没有勇气和信心去重构代码
面对以上这些问题,小明作为一个前端工程师,惯性思维就是每次部署前先在页面上到处点点,然而一个机智的程序员怎么能把大好时间浪费在这些重复劳动上呢,于是小明就去咨询了组里的 Node.js 大牛老王,话说大牛毕竟是大牛,只是高冷的回复了一句:「单元测试」。
于是小明果断去谷歌搜索了「Node.js 单元测试」,毫无意外,一大堆的介绍和教程文章,粗略读了这些文章之后,小明得出了一些关于 Node.js 单元测试的结论,整理如下:
单元测试类型
单元测试分为 TDD(测试驱动开发)和 BDD(行为驱动开发)两种类型,对于这两种类型的比较,小明看的也是云里雾里,感觉单是介绍 TDD 和 BDD 就可以写两篇论文了。不过,选择哪种类型不还是得看代码怎么写嘛,于是小明对比了两种类型的代码:
// TDD |
在对比了两种类型的语法之后,小明毫不犹豫的选择了 BDD,因为 BDD 的语法更加符合人类的思考方式,或者更加语义一点。
单元测试框架
测试框架的职责即提供一套 API 帮助开发者更方便的测试代码。在 JavaScript 社区有两个比较成熟的单元测试框架:jasmine 和 Mocha, 聚焦到 Node.js 社区的话,诸如 koa, express 等多数开源项目使用的都是 Mocha. 小明自然是打开 Mocha 的官网探个究竟,不看不知道,一看吓一跳:
TDD/BDD 语法,异步方法测试,单测前置后置的 hook 等等,堪称完美。来一个简单的示例吧:
var User = require('./models/user'); |
如上示例:首先在执行单测前通过 Mocha 的 before hook 向数据库里添加了一条测试数据,然后测试了 User.find
方法,最后通过 after hook 将这条测试数据删除。这里展示了 Mocha 的 hook 以及测试异步方法,更多的特性小明后续会详细的一一道来。
断言库
断言库即提供一套 API 帮助开发者在单元测试的过程中判定某个值是否符合预期,比如:
// 以 should.js 为例 |
小明从 Mocha 的官网了解到:Mocha 为了保持自身的灵活性,因此默认不提供断言的 API。因此在 Mocha 中你可以使用各种各样的断言库,小明也顺便简单对比了下几种常用断言库:
断言库 | 优点 | 缺点 | 备注 |
---|---|---|---|
Node.js 核心库 Assert | 无需第三方依赖 | 语法较弱 | - |
Should.js | API 非常语义 | 文档太烂 | - |
expect.js | - | - | 比较中庸 |
chai | 大而全的 API | - |
然后小明也简单对比了这几种断言库的语法:
// assert |
从功能上来讲,并无太大的优劣差别,不过写 Should.js 感觉就像写英文语句一般,非常流畅,甚至可以让产品经理也可以时不时来写几行测试代码。小明心想:对于一个程序员来讲,如果有一天可以站在旁边看着产品经理写代码,这种感觉想想都觉得爽。于是小明就暂时选定了 Should.js 作为项目的断言库。
我们都知道小明现在遇到的场景还很简单,只是判断类型啊、值是否相等啊,未来他还会碰到更复杂的场景比如:函数应该抛异常,null/NaN/undefined
的判断……随着踩的坑越多,相信小明也会带来更多的分享。
覆盖率
既然是给功能代码写单元测试,那就应该有个指标去衡量单元测试覆盖了哪些功能代码,这就是接下来要介绍的测试覆盖率。
在 Node.js 中,我们使用 istanbul 作为覆盖率统计的工具,istanbul 可以帮助我们统计到代码的语句覆盖率、分支覆盖率、函数覆盖率以及行覆盖率,生成的报告如下:
小明不禁感叹:「这真是装逼利器啊」。
总结
了解了上面的这一堆概念之后,小明算是对单元测试有了一个初步的认识,同时也觉得单元测试的确是可以解决他在项目里遇到的那些问题。这时候你可能会说:
Talk is cheap. Show me the code.
各位切莫着急,待小明实践之后,再来分享一二。