探知js測試(3)

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

es6模塊測試

模塊語法我這裏說起一點。
如今前端比較流行的模塊寫法有兩種，一種是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來搭載咱們須要進行測試的用例了。

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.

測試API

這裏就主要針對於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);
  });
});

持續集成(CI)

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

(via 阮老師)
持續集成具體的說就是你一天push不少次代碼到github上,而且檢查你全部代碼的測試是否經過。
對於github，travis-cli就是用來幫助你完成這一系列構建的。
這裏，我講解一下基本的配置流程。

1. 打開travis-cli官網，而後綁定你的github帳號

2. 在你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~