Node实战（第2季）6 Node.js测试服务搭建

6.1 概述

    目的：写过电子邮件爬虫、基于RESTful的API服务器、服务中间件、类似于ZooKeeper的集群管理系统，以及应用服务器，在此期间也产出了不下100个与Node.js相关的模块。

    本章主要介绍笔者在过去半年内与一家时尚杂志相关的互联网创业团队合作的部分经历，其中最重要的部分工作就是为该团队搭建了一套较基础的测试服务，测试范围涵盖服务器、浏览器、Mag+、Adobe InDesign等平台。希望通过分享这几个月的实践，能够帮助大家找到一种更为全面、完整的方式去保证项目代码的质量。

    Pixbi：通过给电子杂志出版商开发一个专用的Adobe InDesign插件，以让他们在发布的电子杂志中提供一些商品的购买链接，这样消费者在阅读相应的页面时，可以直接购买、收藏及分享自己喜欢的商品如手表、外套、运动短裤等，也可以通过安装了Pixbi应用的iPhone手机对以及打开的杂志进行扫码购买。

     项目主要的技术栈：

• 使用Node.js作为API服务器平台，实现一个基础的用户系统。
• 由于Pixbi的主要服务是将商品的图片转换为购买的链接，因此需要使用诸如AWS Product Adverting之类的第三方数据接口，这也是之后会引入SinonJS的主要原因。
• Pixbi的UI逻辑代码会被集成到iOS的杂志应用中，当时使用了Mag+平台，我们通过构建工具将前端代码按照Mag+的要求打包，然后在用户浏览时以file://协议进行访问。所以对于此部分代码的测试，为了尽量保证测试环境与实际运行环境的相同，就需要在测试前端功能时，同样以文件协议打开。
• Pixbi会提供给杂志出版商一个Adobe InDesign插件，Adobe InDesign插件的环境本身比较复杂（称之的Adobe InDesign DOM），并且混合了Node.js的API。因此在对这个插件进行测试覆盖时，确实遇到了不小的麻烦。

6.2 搭建后端测试服务

    针对后端测试服务的搭建，一般分为单元测试、功能性测试及可拓展性测试，通常来说，进行分布验证。

    技术栈来进行后端测试服务的搭建：

MochaJS

SinonJS

Node.js

jscoverage

    单元测试：分三部分

（1）通过书写测试用例来描述最终的商业逻辑及预期结果

（2）确保1中的测试用例拥有足够高的测试覆盖率。

（3）单元测试只需确保项目“源”代码的可用性，对于node_modules的代码，我们需要在对应的模组中进行测试。

    功能性测试：单元测试的着眼点为代码库，而功能性测试则偏重于产品方向，因此检验服务器的各个接口是否完整，以及主要业务流程是否完善即为功能性测试的主要作用，也是产品上线前的重要工序。

    部署环境，

    可拓展性测试：

6.3 搭建前端测试服务

    作为最接近用户层的技术，前端在被测体中占据着非常重要的一部分，然而要完整、高自动化地对前端进行测试，还有着非常大的挑战及难度，特别是针对Pixbi这种多终端的客户体验，其客户端包括Adobe插件、Mag+、Chrome插件及浏览器环境等。

    另外，由于前端需要UI渲染，所以测试代码的代价高于服务器端的单元测试，自动化难度系数相对较高。不过好在我们找到了PhamtomJS和BrowserStack这两个开源服务，使整个前端测试流程变得足够简单，下面我们先从PhantomJS开始。

    PhantomJS：Pixbi用的前端构建工具https://github.com/pixbi/duplo

    BrowserStack：在Headless浏览器/PhantomJS环境下，只能用来测试一些比较基础的JavaScript代码。为了更全面、可靠地测试与用户界面相关的部分，我们需要一个真实的浏览器环境来进行测试。

    browserstack.com集成了将近700个浏览器的测试环境，并内建WebDriver的API。下面就来看看如何在项目中使用BrowserStack服务。

    Adobe CEP ： 

6.4 加入持续集成工作流