摘要：模塊測(cè)試模塊語(yǔ)法我這里提及一點(diǎn)。基本工程目錄一個(gè)良好的工程目錄，能夠幫助你測(cè)試成本降到最低。這一塊算是獨(dú)立于單元測(cè)試的。

前面兩篇已經(jīng)把，js測(cè)試的模式，框架，斷言庫(kù)基本介紹了一遍。這里，我們要上升到整體測(cè)試架構(gòu)上來(lái).
首先，單元測(cè)試的對(duì)象是模塊，這里我們就要將自己測(cè)試目標(biāo)調(diào)整到對(duì)模塊測(cè)試上來(lái)。所以，這里我們需要使用CommonJS或者es6的模塊的寫法了。
另外需要了解,mocha框架測(cè)試的一些基本原理。 通過(guò)建立清晰的工程目錄，才能讓你的測(cè)試更加清晰。

模塊語(yǔ)法我這里提及一點(diǎn)。
現(xiàn)在前端比較流行的模塊寫法有兩種，一種是commonJS規(guī)范，另外一種是未來(lái)es6的普遍寫法。
commonJS規(guī)范寫法:

//寫一個(gè)模塊并且導(dǎo)出,存放在add.js文件下
var add = (num1,num2)=>num1+num2;
exports.add = add;
//引入add.js文件并調(diào)用
var test = require("./add.js");
test.add(1,2);  //值應(yīng)該為3

es6的寫法:

var add = (num1,num2)=>num1+num2;
export {add};
//引入模塊
import {add} from "./demo.js";
console.log(add(1,2));

但是由于nodeJS默認(rèn)支持的是commonJS的寫法,所以上文的es6只當(dāng)做介紹吧。

一個(gè)良好的工程目錄，能夠幫助你測(cè)試成本降到最低。這里我們以mocha為基本框架。 mocha測(cè)試會(huì)默認(rèn)以你的test目錄作為測(cè)試文件所在。即，你的所有測(cè)試用例都應(yīng)該放到test文件夾下面. 而且如果以后你去寫一個(gè)插件，并且附上test目錄，這是能夠讓人相信你的插件的可用性的(因?yàn)槲乙呀?jīng)測(cè)試過(guò)了呀~).
don"t waste time~
基本目錄結(jié)構(gòu)應(yīng)該想這樣的.

test
src(js)
... //相應(yīng)的配置文件，比如makefile,.babelrc等

有興趣的同學(xué)可以看一下。我的目錄
Ok,目錄搭好了之后。開始說(shuō)一下mocha測(cè)試的內(nèi)涵了.
在前文，使用mocha測(cè)試的時(shí)候
使用的命令如下:

mocha test.js

而在這樣的目錄結(jié)構(gòu)中(在和node_modules同級(jí)目錄下)，可以直接使用

mocha     //后面不要任何參數(shù)

他便會(huì)遍歷你的test文件夾的第一層js文件，并找出測(cè)試語(yǔ)句并測(cè)試。
但是，我們?cè)跍y(cè)試的時(shí)候往往還需要分目錄進(jìn)行測(cè)試.
所以這里需要使用到mocha的一個(gè)參數(shù).

mocha --recursive

recursive中文意思是遞歸的意思。那，這就很明顯了。 使用recursive的參數(shù)，mocha會(huì)遍歷你目錄下所有的文件，執(zhí)行測(cè)試。
這也是mocha最有用的一個(gè)參數(shù).
另外，想想，如果你的測(cè)試用例寫錯(cuò)了。那么你需要手動(dòng)進(jìn)行更改。 而且改動(dòng)完了之后還需要重啟mocha，這尼瑪超級(jí)煩人的哎喂。 所以，mocha之所以這么吸引人就是因?yàn)樗娜诵曰?br>mocah提供了你一個(gè)參數(shù)--watch

mocha --watch

這樣mocha框架會(huì)持續(xù)監(jiān)聽你的文件，如果有改動(dòng)的話則會(huì)重新測(cè)試.
還有一個(gè)樣式文件,可以輸出一些不一樣的mocha風(fēng)格(要記住，做一名有情懷的程序員)
這里我提供給大家兩個(gè)我比較喜歡的。一個(gè)是萌系，一個(gè)是職場(chǎng)魅力.

//萌系
mocha --reporter nyan
//職場(chǎng)魅力
mocah --reporter tap

上張圖吧。

本人，是個(gè)寶寶。 所以超級(jí)喜歡第二個(gè)。 但是到大人(leader)面前，會(huì)用tap來(lái)裝裝逼的.
這時(shí)候，我想想應(yīng)該有人會(huì)崩潰的。
md，這么多參數(shù)，我怎么配呀。。。
mocha早已看穿一切。
它用mocha.opts讓你不知不覺的跪在地板上。
只要我們把 mocha.opts配置好了，那么我們就可以直接使用

mocha

運(yùn)行測(cè)試
個(gè)人比較青睞于這3個(gè)參數(shù).另外mocha.opts文件是放在test的根目錄下的.

--recursive (必不可少)
--reporter nyan(萌萌噠)
--watch

OK. 我這里有個(gè)實(shí)例，大家可以參考。
還有，如果你想生成一個(gè)測(cè)試規(guī)格文件(markdown)，可以直接使用

mocha --recursive -R markdown > spec.md

如果你想生成html文件，也可以使用

mocha --recursive -R doc > spec.html

ok~ 基本操作，我們已經(jīng)有點(diǎn)心得體會(huì)了。 不過(guò)，就像我所說(shuō)的那樣，測(cè)試
不僅能讓你的代碼，完美通過(guò)。還要保證的你代碼質(zhì)量有相當(dāng)高的質(zhì)量. 而 保證你高質(zhì)量代碼的工具就是代碼覆蓋率測(cè)試。這一塊算是獨(dú)立于單元測(cè)試的。 在前端最常用的就是使用istabul.
首先應(yīng)該下載istanbul:

npm install -g istanbul

這時(shí)候，istanbul已經(jīng)下載到你的全局目錄下。 你可以在你電腦的任意角落運(yùn)行istanbul的相關(guān)命令.但是，本寶寶不想碼字。所以，我這里僅僅介紹istanbul的官網(wǎng)上面推薦的一個(gè)黃金order：

istanbul cover xxx.js

使用istanbul檢查指定的文件，并且他會(huì)在當(dāng)前的目錄下，生出一個(gè)coverage directory。 里面包含了你測(cè)試文件的GUI(就是HTML啦~),你可以打開來(lái)看一下，挺好看的哦(才怪).
如果你想測(cè)試test目錄下的話，可以使用:

istanbul cover test/*.js

但是，結(jié)果肯定是不會(huì)通過(guò)的，因?yàn)閕stanbul的默認(rèn)引擎是ECMA的，但是, 在test目錄下，充斥的是mocha測(cè)試框架的地盤誒~

istanbul: js,js,js快開門，我是你的測(cè)試媽媽呀~
js: 不開，不開，我不開，mocha媽媽沒回來(lái)

就是這個(gè)感覺，所以造成的問(wèn)題就是,istanbul根本動(dòng)不了test目錄下的。 呵呵，你以為istanbul就這樣放棄了嗎？ 你知道istanbul的學(xué)名叫什么嗎？ 地毯推銷
不認(rèn)我這個(gè)媽？ 那我當(dāng)你奶奶吧。
就這樣。istanbul又多出一個(gè)命令:

istanbul cover _mocha

現(xiàn)在istanbul比mocha更高一級(jí)。 他會(huì)騎著mocha馳騁在測(cè)試的領(lǐng)域里。mocha在哪，他就在哪。當(dāng)mocha運(yùn)行完的時(shí)候，他就會(huì)生成測(cè)試報(bào)告.
還記得，上面所說(shuō)的mocha.opts嗎？
其實(shí)，這只是最流行的做法的一塊墊腳石，最流行的做法就是配置makefile文件。有興趣的同學(xué)，可以參考我的前一篇blog.
這時(shí)候，我們就可以使用makefile來(lái)搭載我們需要進(jìn)行測(cè)試的用例了。

我們先來(lái)看一個(gè)比較簡(jiǎn)單的:

test:
        istanbul cover _mocha
.PHONY:test

由于在本寶寶的電腦上，istanbul和mocha都是全局安裝，所以，這里不需要指明指定的.bin文件的目錄。而且，mocha的參數(shù)已經(jīng)在mocha.opts里面已經(jīng)配置好了。 不過(guò)，如果你想自定義一些參數(shù)的話，可以在_mocha后面?zhèn)魅雲(yún)?shù)，這時(shí)候，你可以完全拋棄mocha.opts了。因?yàn)閙ake已經(jīng)讓你知道什么叫做 muscle

OPTS:=--recursive --reporter nyan --watch
test:
        mocha $(OPTS)
cover:
        istanbul cover _mocha -- $(OPTS)
.PHONY:test

當(dāng)然，比較裝逼的做法就是，就是使用本地的node_modules，確保版本的統(tǒng)一(不過(guò)，推薦安裝到全局，這樣其他項(xiàng)目也方便用。而且方便配置).

show u the code

ISTANBUL=./node_modules/.bin/istanbul
_MOCHA=./node_modules/.bin/_mocha
MOCHA=./node_modules/.bin/mocha
OPTS:=--recursive --reporter nyan --watch
test:
        @$(MOCHA) $(OPTS) #省略命令的輸出
cover:
        @$(ISTANBUL) cover $(_MOCHA) -- $(OPTS)
.PHONY:test cover

這只是一個(gè)小小的示范。 隨著你項(xiàng)目的壯大，你后面的測(cè)試會(huì)越來(lái)越復(fù)雜，makefile在后面的測(cè)試體現(xiàn)的效果也越大。
不過(guò)通常，我使用makefile還有一個(gè)特點(diǎn)就是它強(qiáng)大的組合命令能力。我在前一篇blog里面也說(shuō)過(guò)了。 這里再炒一遍。
makefile的基本格式為:

target:prerequisties
[TAB]command

他組合命令就體現(xiàn)在prerequisties。
我們可以使用prerequisties組合出我們想要的測(cè)試效果.

testDemo:
        mocha "test/test.js"
testNest:testDemo
        mocha "test/nested/test1.js"

當(dāng)你指定make testNest的時(shí)候，執(zhí)行順序會(huì)testDemo-> testNest.

這里就主要針對(duì)于nodeJS而言的，當(dāng)我們寫好一個(gè)接口的時(shí)候，都需要進(jìn)行相應(yīng)的測(cè)試，才能交給前端去使用，不然的話，真的是！害！人！害！己啊。
以前沒有了解測(cè)試，通常是使用網(wǎng)頁(yè)測(cè)試，比如Advanced REST client，導(dǎo)致的結(jié)果就是測(cè)試過(guò)的后面加需求之后，更改，然后又出現(xiàn)以前的bug，然后測(cè)試的demo就刪了寫(蛋疼)，而不能有很好的目錄測(cè)試。
這里，介紹一個(gè)很棒的測(cè)試框架supertest.該框架能夠模擬你的接口，并且發(fā)送相應(yīng)的請(qǐng)求過(guò)去，然后對(duì)返回的數(shù)據(jù)進(jìn)行驗(yàn)證,而且他設(shè)置的結(jié)果是ephmeral(短暫的),所以這就省去了你開啟接口，然后關(guān)閉，然后在打開這樣無(wú)腦的行為。 這樣，不僅能讓你很好的保存你測(cè)試的用例，并且可以實(shí)現(xiàn)完美的自定義化.
看個(gè)demo:

var express = require("express");
var request = require("supertest");
var app = express();
var expect = require("chai").expect;

// 定義路由
app.get("/user", function(req, res){
  res.status(200).send({ name: "get it" });
});

describe("GET /user", function(){
  it("respond with json", function(done){
    request(app)
      .get("/user")
      .set("Accept", "application/json")
      .expect("Content-Type", /json/)
      .expect(200)
      .end(function (err, res) {
        if (err){
          done(err);
        }
        expect(res.body.name).to.equal("get it");
        done();
      })
  });
});

要知道測(cè)試API的時(shí)候，是異步測(cè)試，所以這里需要引入mocha的done測(cè)試，讓你能夠很好的解決異步的問(wèn)題。
另外，一般測(cè)試的時(shí)候，我們并不需要這么寫的詳細(xì)，寫的時(shí)候一定要找準(zhǔn)自己的測(cè)試點(diǎn)。 一般而言，測(cè)試一個(gè)接口就是測(cè)試他的 類型，返回值，發(fā)送數(shù)據(jù)格式等基本項(xiàng)。
上面只是一個(gè)簡(jiǎn)單的demo,詳細(xì)的可以參考supertest的測(cè)試用例.
栗子:

// 定義路由
describe("POST /user", function(){
  it("should work with .send() etc", function(done){
    var app = express();

    app.use(bodyParser.json());

    app.post("/", function(req, res){
      res.send(req.body.name);
    });

    request(app)
    .post("/")
    .send({ name: "jimmy" })
    .expect("jimmy", done);
  });
});

首先說(shuō)明一下，什么是持續(xù)集成

(via 阮老師)
持續(xù)集成具體的說(shuō)就是你一天push很多次代碼到github上,并且檢查你所有代碼的測(cè)試是否通過(guò)。
對(duì)于github，travis-cli就是用來(lái)幫助你完成這一系列構(gòu)建的。
這里，我講解一下基本的配置流程。

打開travis-cli官網(wǎng)，然后綁定你的github賬號(hào)

在你git根目錄下，新建.travis.yml文件。根據(jù)你項(xiàng)目的語(yǔ)言選擇合適的，作為前端的寶寶。 我們使用node就可以了

language: node_js
node_js:
  - "5"
  - "4"

3.?在npm scripts里面設(shè)置test命令，通常情況下使用

test:mocha --recursive --reporter spec

4.最后push你的代碼到遠(yuǎn)端倉(cāng)庫(kù)， travis-cli會(huì)自動(dòng)執(zhí)行npm run test. 進(jìn)行檢測(cè)。 所以，這里的test一定要寫全，需要對(duì)你所有的檢測(cè)用例都檢測(cè)一遍才可以。
這里，我有個(gè)demo.大家如果有興趣，可以參閱。
其實(shí)，還有一個(gè)UI測(cè)試。這里，我就不做過(guò)多的贅述了， 因?yàn)椋瑢殞氂X得UI測(cè)試，還是直觀上方便一些。
在正式的場(chǎng)合里面(leader), 多寫測(cè)試，不僅能讓你的代碼有更好的可信度，而且也能讓你置于和產(chǎn)經(jīng)撕逼的不敗地位。
ending~