Syshen's Murmur

用 mocha 編寫 Node.js unit test

以往在缺乏好的 framework 下，所以一直少有人注意 javascript 的 unit testing，而且在做 frontend 時，整合測試比 unit testing 來得重要，因為多數的問題都出在瀏覽器相容性上，或者與介面的互動上。不過在這個 Node.js 大放光彩的時代，每天都有無數的開發者為 Node.js 開發模組，對一般開發者來說，有這麼多模組可以用當然開心，因為不需要自己再去發明輪子，但是卻也帶來另外一個隱憂 — 四處可見不穩定甚至未經測試的模組，所以當我們在選定一個模組時，最好是要注意該模組是否有完整的測試程式，這是用來審視原作者對於模組的程式品質是否在意的重要指標。

目前有幾套一開始專為 node.js 專案而開發的 unit testing framework，例如 nodeunit、vows、跟這一篇要介紹的 mocha。我個人使用過 vows 跟 mocha，其實這兩套 framework 大同小異，他們都是 BDD 類型的 unit testing (mocha 支援其他種開發方式，如 TDD)，都能過產生各類的測試結果報表，如 spec、xunit 等，目前兩者也都廣泛被其他 Node.js 模組所採用，但我個人偏好使用 mocha，原因是它比 vows 更簡潔容易。

Mocha 的主要作者是 Node.js 裡的名人 TJ Holowaychuk，重量級的 web framework - express 就是他的另外一個作品。

要用 mocha 編寫測試程式，首先就要了解一下 BDD 的概念，BDD 的全名是 Behavior Driven Development，要了解什麼是 BDD 可以先看一下這篇文章：http://dannorth.net/whats-in-a-story/

有別於傳統 TDD 的開發流程，BDD 從 user story 出發來編寫測試程式，所以在測試的描述裡多半會寫成如 “When [scenario], giving [conditions], it should [expected results]” 的字句，這麼做的好處是，除了可以確保你的程式不會超出或者小於 user story 的範圍外，而且當主程式寫錯時，你立刻可以知道哪些 user story 受到影響，而且影響的範圍有多大。所以因為如此，當採用 agile 或者 scrum 的開發流程時，BDD 會是一個很好用的工具。

底下的範例會用一個我正在寫的 Node.js 模組 nodeha 為例，這是一個簡單的 reversed proxy 模組，可以用來作 load balancing 跟服務的 high avaliability，模組原始程式碼在 https://github.com/waveface/nodeha (目前還在開發當中，歡迎有興趣的人一起參與)

一個簡單的 mocha 測試程式如下：

每一個 test case 都是以 describe() 函式開始，用 describe 來描述每個 test case 所要測試的情境(scenario)，describe 可以一層一層呼叫下去，用起來的感覺就會很像在層層描述所要測試的情境。而你要驗證的結果要放在 it() 函式裡，會用 it 是因為它在英文裡是一個主詞，所以 it 裡第一個參數會是個字串，用來描述你所預期的測試結果，通常會用 “should xxxx” 來表示，接起來看的話就會是 “it should xxxx”。

上面的程式是同步執行的，第一個 test 結束後才會接下一個，不過在 javascript 裡多的是 asynchronous 的程式用法，所以能不能測 async 程式，容不容易寫，也是檢視一個 unit testing framework 好不好用很重要的指標，而在 mocha 裡，測 async 程式是很簡單的事，訣竅在於多個 done() 的函式呼叫。

如果你要驗證的結果會在某個 callback 裡被傳入，在使用 it() 呼叫時，it() 的 callback 會帶給你一個參數，這是一個 function 的 reference ，通常我們會把它命名為 done，你必須在驗證完結果再呼叫 done()，如此一來 mocha 才知道這個 test case 已經執行結束。

當你編寫完程式程式後，簡單執行的方法就是：

% mocha test.js

test.js 就是你的測試程式。mocha 還些不錯的功能，像是在執行過程中偵測變數是否有變數 leak 的情況，雖然這個功能可以幫我們找到一些可能的 bug，但在某些情況下還挺煩人的，所以如果不想要讓 mocha 抱怨這個錯誤的話，可以在執行時加上 —ignore-leaks 的參數。

mocha 支援多種執行結果的顯示模式，如果你想要跟一些 CI 的流程做整合，如 jenkins ，那麼可以試著用 xunit 的格式，如果只想要單純知道測試結果成功或者失敗，可以不加任何參數，那麼 mocha 就會用 unit testing 最常見的格式，以點點點來表示總共測試了多少項目，哪些成功哪些失敗。至於我最常用的是 list 跟 spec。list 格式是將所有測試的 story 從上到下排列下來，而 spec 則是根據 scenario 做 grouping，各有好處，但我覺得這樣的顯示方式最適合 BDD 的精神，最容易理解測試對於 user story 的影響。要指定哪種輸出方式只需要給予 -R 以及輸出格式的名稱即可，如 “-R spec” 。

-R spec

-R list

-R xunit

使用 BDD 時可以用 Node.js 內建的 assert() 函式來驗證程式執行結果，但是一般來說也會使用同是 TJ 寫的 should.js 模組，使用 should 模組的好處是連驗證程式的風格都具備 BDD style，例如：

should.not.be.true(ret);

或者

a.should.equal(“hello”);

當 should.js 模組被引入時，會自動在所有物件中置入 should 屬性，所以你可以在任何物件後面接上 should 來執行檢驗。

mocha 功能五花八門，甚至不只支援 BDD 模式，也同時支援 TDD 開發模式。在 TDD 開發下，不再使用如 describe() 跟 it() 函式，而是改用 suite() 、setup() 與 test()，同時也不太會再用 should 模組，而是直接使用 Node 中的 assert() 函式，執行測試時也必須加上 —ui tdd 的參數來表明這是一個 tdd 的測試程式。