摘要：模塊測試模塊語法我這里提及一點?；竟こ棠夸浺粋€良好的工程目錄，能夠幫助你測試成本降到最低。這一塊算是獨立于單元測試的。

前面兩篇已經把，js測試的模式，框架，斷言庫基本介紹了一遍。這里，我們要上升到整體測試架構上來.
首先，單元測試的對象是模塊，這里我們就要將自己測試目標調整到對模塊測試上來。所以，這里我們需要使用CommonJS或者es6的模塊的寫法了。
另外需要了解,mocha框架測試的一些基本原理。 通過建立清晰的工程目錄，才能讓你的測試更加清晰。

模塊語法我這里提及一點。
現在前端比較流行的模塊寫法有兩種，一種是commonJS規范，另外一種是未來es6的普遍寫法。
commonJS規范寫法:

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

es6的寫法:

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

但是由于nodeJS默認支持的是commonJS的寫法,所以上文的es6只當做介紹吧。

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

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

有興趣的同學可以看一下。我的目錄
Ok,目錄搭好了之后。開始說一下mocha測試的內涵了.
在前文，使用mocha測試的時候
使用的命令如下:

mocha test.js

而在這樣的目錄結構中(在和node_modules同級目錄下)，可以直接使用

mocha     //后面不要任何參數

他便會遍歷你的test文件夾的第一層js文件，并找出測試語句并測試。
但是，我們在測試的時候往往還需要分目錄進行測試.
所以這里需要使用到mocha的一個參數.

mocha --recursive

recursive中文意思是遞歸的意思。那，這就很明顯了。 使用recursive的參數，mocha會遍歷你目錄下所有的文件，執行測試。
這也是mocha最有用的一個參數.
另外，想想，如果你的測試用例寫錯了。那么你需要手動進行更改。 而且改動完了之后還需要重啟mocha，這尼瑪超級煩人的哎喂。 所以，mocha之所以這么吸引人就是因為他的人性化。
mocah提供了你一個參數--watch

mocha --watch

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

//萌系
mocha --reporter nyan
//職場魅力
mocah --reporter tap

上張圖吧。

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

mocha

運行測試
個人比較青睞于這3個參數.另外mocha.opts文件是放在test的根目錄下的.

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

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

mocha --recursive -R markdown > spec.md

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

mocha --recursive -R doc > spec.html

ok~ 基本操作，我們已經有點心得體會了。 不過，就像我所說的那樣，測試
不僅能讓你的代碼，完美通過。還要保證的你代碼質量有相當高的質量. 而 保證你高質量代碼的工具就是代碼覆蓋率測試。這一塊算是獨立于單元測試的。 在前端最常用的就是使用istabul.
首先應該下載istanbul:

npm install -g istanbul

這時候，istanbul已經下載到你的全局目錄下。 你可以在你電腦的任意角落運行istanbul的相關命令.但是，本寶寶不想碼字。所以，我這里僅僅介紹istanbul的官網上面推薦的一個黃金order：

istanbul cover xxx.js

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

istanbul cover test/*.js

但是，結果肯定是不會通過的，因為istanbul的默認引擎是ECMA的，但是, 在test目錄下，充斥的是mocha測試框架的地盤誒~

istanbul: js,js,js快開門，我是你的測試媽媽呀~
js: 不開，不開，我不開，mocha媽媽沒回來

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

istanbul cover _mocha

現在istanbul比mocha更高一級。 他會騎著mocha馳騁在測試的領域里。mocha在哪，他就在哪。當mocha運行完的時候，他就會生成測試報告.
還記得，上面所說的mocha.opts嗎？
其實，這只是最流行的做法的一塊墊腳石，最流行的做法就是配置makefile文件。有興趣的同學，可以參考我的前一篇blog.
這時候，我們就可以使用makefile來搭載我們需要進行測試的用例了。

我們先來看一個比較簡單的:

test:
        istanbul cover _mocha
.PHONY:test

由于在本寶寶的電腦上，istanbul和mocha都是全局安裝，所以，這里不需要指明指定的.bin文件的目錄。而且，mocha的參數已經在mocha.opts里面已經配置好了。 不過，如果你想自定義一些參數的話，可以在_mocha后面傳入參數，這時候，你可以完全拋棄mocha.opts了。因為make已經讓你知道什么叫做 muscle

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

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

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

這只是一個小小的示范。 隨著你項目的壯大，你后面的測試會越來越復雜，makefile在后面的測試體現的效果也越大。
不過通常，我使用makefile還有一個特點就是它強大的組合命令能力。我在前一篇blog里面也說過了。 這里再炒一遍。
makefile的基本格式為:

target:prerequisties
[TAB]command

他組合命令就體現在prerequisties。
我們可以使用prerequisties組合出我們想要的測試效果.

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

當你指定make testNest的時候，執行順序會testDemo-> testNest.

這里就主要針對于nodeJS而言的，當我們寫好一個接口的時候，都需要進行相應的測試，才能交給前端去使用，不然的話，真的是！害！人！害！己啊。
以前沒有了解測試，通常是使用網頁測試，比如Advanced REST client，導致的結果就是測試過的后面加需求之后，更改，然后又出現以前的bug，然后測試的demo就刪了寫(蛋疼)，而不能有很好的目錄測試。
這里，介紹一個很棒的測試框架supertest.該框架能夠模擬你的接口，并且發送相應的請求過去，然后對返回的數據進行驗證,而且他設置的結果是ephmeral(短暫的),所以這就省去了你開啟接口，然后關閉，然后在打開這樣無腦的行為。 這樣，不僅能讓你很好的保存你測試的用例，并且可以實現完美的自定義化.
看個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();
      })
  });
});

要知道測試API的時候，是異步測試，所以這里需要引入mocha的done測試，讓你能夠很好的解決異步的問題。
另外，一般測試的時候，我們并不需要這么寫的詳細，寫的時候一定要找準自己的測試點。 一般而言，測試一個接口就是測試他的 類型，返回值，發送數據格式等基本項。
上面只是一個簡單的demo,詳細的可以參考supertest的測試用例.
栗子:

// 定義路由
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);
  });
});

首先說明一下，什么是持續集成

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

打開travis-cli官網，然后綁定你的github賬號

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

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

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

test:mocha --recursive --reporter spec

4.最后push你的代碼到遠端倉庫， travis-cli會自動執行npm run test. 進行檢測。 所以，這里的test一定要寫全，需要對你所有的檢測用例都檢測一遍才可以。
這里，我有個demo.大家如果有興趣，可以參閱。
其實，還有一個UI測試。這里，我就不做過多的贅述了， 因為，寶寶覺得UI測試，還是直觀上方便一些。
在正式的場合里面(leader), 多寫測試，不僅能讓你的代碼有更好的可信度，而且也能讓你置于和產經撕逼的不敗地位。
ending~