早就知道單元測試這樣一個概念，但是一直沒有使用到；只知道後端用到單元測試；直到最近，在真正開始接觸和使用它。究竟什麼是單元測試？很多人也不一定能描述的十分清楚，故整理記錄下，以備自己檢視同時幫助他人。

waht is the unit test ?

In computer programming, unit testing is a method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures are tested to determine if they are fit for use.

以上是為基本百科的解釋；重點在於最後，單元測試的目的是用來確定是否適合使用。而測試的方法則包括控制資料，使用和操作過程。開發人員需要使用程式碼來定義一個可用的衡量標準，並且可以快速檢驗。

why  use  unit test ?

長期以來，前端開發的單元測試並不是在前端的開發過程中所必須的，也不是每個前端開發工程師所注意和重視的，甚至擴大到軟體開發過程中單元測試這一環也不是在章程上有書面規定所要求的。但是隨著每個工程的複雜化、程式碼的高複用性要求和前端程式碼模組之間的高內聚低耦合的需求，前端工程中的單元測試流程就顯得很有其必要。

不僅僅是這樣。許多人認為單元測試，甚至整個測試都是在編碼結束後的一道工序，但測試應該伴隨整個編碼或軟體週期進行，還有將在後面提到的TDD這樣有趣的東西，單元測試將超前於編碼。單元測試應該是一個框架、標準，經常被形容被腳手架，甚至一開始就搭好腳手架。

保證重構----網際網路行業產品迭代速度很快，迭代後必然存在程式碼重構的過程，那怎麼才能保證重構後代碼的質量呢？有測試用例做後盾，就可以大膽的進行重構。

how to use unot test ?

1.原則

• 測試程式碼時，只考慮測試，不考慮內部實現
• 資料儘量模擬現實，越靠近現實越好
• 充分考慮資料的邊界條件
• 對重點、複雜、核心程式碼，重點測試
• 利用AOP(beforeEach、afterEach),減少測試程式碼數量，避免無用功能
• 測試、功能開發相結合，有利於設計和程式碼重構

2.單元測試方法論

簡單來說，TDD是一種相對於普通思維的方式來說，比較極端的一種做法。我們一般能想到的是先編寫業務程式碼，然後為其編寫測試程式碼，用來驗證產品方法是不是按照設計工作。而TDD的思想正好與之相反，在TDD的世界中，我們應該首先根據需求或者介面情況編寫測試，然後再根據測試來編寫業務程式碼。BDD更加註重業務需求而不是技術，雖然看起來BDD確實是比TDD做的更好，但這是一種誤導，這僅僅是就某種環境下而言的。而且以國內的現狀來看TDD要比BDD更適合，因為它不需要所有人員的理解和加入。

3.前端單元測試工作流

那麼怎樣用常用框架進行單元測試？單元測試的工具環境是什麼？單元測試的實際示例是怎樣的？

先介紹集中單元測試的框架：-------

Mocha：mocha 是一個功能豐富的前端測試框架。

Mocha is a feature-rich JavaScript test framework running on Node.js and in the browser, making asynchronous testing simple and fun. Mocha tests run serially, allowing for flexible and accurate reporting, while mapping uncaught exceptions to the correct test cases. Hosted on GitHub.

Karma：一個基於Node.js的JavaScript測試執行過程管理工具（Test Runner）。該工具可用於測試所有主流Web瀏覽器，也可整合到CI（Continuous integration）工具，也可和其他程式碼編輯器一起使用。這個測試工具的一個強大特性就是，它可以監控檔案的變化，然後自行執行，通過console.log顯示測試結果。Karma的一個強大特性就是，它可以監控一套檔案的變換，並立即開始測試已儲存的檔案，使用者無需離開文字編輯器。測試結果通常顯示在命令列中，而非程式碼編輯器。這也就讓 Karma 基本可以和任何 JS 編輯器一起使用。

Travis.CI: 提供的是持續整合服務（Continuous Integration，簡稱 CI）。它繫結 Github 上面的專案，只要有新的程式碼，就會自動抓取。然後，提供一個執行環境，執行測試，完成構建，還能部署到伺服器。

持續整合的好處在於，每次程式碼的小幅變更，就能看到執行結果，從而不斷累積小的變更，而不是在開發週期結束時，一下子合併一大塊程式碼。

然後你還需要斷言庫：---

• C-style TDD 斷言庫

• BDD 風格斷言庫

• 追求極簡的 BDD 風格斷言庫

• 基於 should.js 簡化

chai

• BDD/TDD 雙模 ，同時支援 should / expect / assert 三種風格的斷言庫 強大外掛機制

我目前比較傾向於我目前傾向於 Mocha + Chai 的測試方案 -------------------------------------------Mocha + Chai 的具體安裝使用例項詳見下一篇