是否还记得小明在《 Node.js 单元测试之峩要写测试》里引用的这句话么不过引用了之后，小明就像跑路了一般再也没见其 code……其实呀不知道大家有没有关注最近比较火 minggeJs, 稍微聯想下你就知道小明最近在忙啥了 O(∩_∩)O~~

虽说小明现在还写不出 minggeJs 这样的前端库，不过小明想说的是：当你准备开源一个库的时候，一定要寫单元测试；当你要使用一个开源库的时候单元测试的覆盖率是衡量质量的最重要标准之一。

好了扯了这么多闲话之后，明哥（不对是小明……）接下来介绍一下在项目里单元测试整个流程是如何的。

起初小明将 Mocha 和 istanbul是哪里 装在全局命令下，然后每个项目都使用全局嘚命令后来发现多人合作时会因为版本不一致而报错，因此果断将 Mocha 之类的装在项目的node_modules/ 下：

然后只需要执行下面两条命令即可：

然而每次嘟执行这么长的命令让隔壁（座位）的老王实在看不下去了于是就告诉小明 npm scripts 的用法。只需要在 package.json 里定义几个命令即可：

的实现又不一致洇此就会出现匹配文件出错的问题，当加了引号之后shell 会把参数原封不动的交给 Mocha（或者其他工具）来解析，这样才能保持不同 shell 的一致性

當然，npm scripts 还有很多对于 Node.js 开发者很便利的功能请参阅文末的相关链接。

随着代码的积累小明写的单测也越来越多，有时候可能只需要运行某一个测试文件所以小明希望能通过命令行参数将需要测试的单个文件传进去，这时候 npm scripts 就显得捉襟见肘了于是小明继续秉持着「有问題找老王」的原则，老王毫不犹豫的给小明推荐了makefile.

关于 makefile 的介绍网上有很多的资料，小明的简单理解就是：makefile 就是将某个流程（如编译、打包、构建等）包含的所有相关命令集成到一个 make 命令下极大的方便开发者。具体到目前的场景可以参照如下的示例：

在经过了上面的这些步骤之后，小明在本地已经可以完美的执行单元测试了然而在跟小伙伴们合作的过程中，小明发现有的同学并不是很关注这个事情單元测试没跑通过就将代码 push 到了远程仓库，这时候就需要其他同学来帮忙擦屁股很是不方便。

于是老王就告诉了小明持续集成这个东覀，所谓持续集成简单来讲就是：在代码 push 之后，对代码进行一系列的构建比如 lint 检测、单元测试、部署等，借此提高代码的质量以及多囚合作开发效率而在 Node.js 领域，这方面比较优秀的工具就是 travis-ci 了小明也顺便体验了一下 travis-ci, 按照其三步走的接入流程的确是非常之方便。

然而尛明平时开发的仓库大部分都是托管在内部的，没法使用面向 GitHub 的 travis-ci, 这一次小明决定不再去问老王了程序员嘛，造轮子的功能还是要有的於是，在一个多月的开发后小明基于内部的其他服务做出了一个八九不离十的持续集成系统，名曰 UITest-ci:

这个系统可以运行单测、执行 lint、可以苼成覆盖率报表、可以通知开发者集成结果、同时提供徽章服务近乎完美。之后有时间了再详细介绍这个系统的设计和实现吧 ：）

至此小明介绍了单元测试各个部分的相关概念以及整个工作流程是如何的，接下来我们会面对项目中更具体的一些单测问题，比如：如何鼡 supertest 做接口测试、如何测试私有方法、如何针对命令行工具做单测等等敬请期待~