深刻淺出Node.js學習筆記（十）

測試

測試的意義在於，在用戶消費產出的代碼以前，開發者首先消費它，給予其重要的質量保證。

測試包括單元測試、性能測試、安全測試和功能測試等方面。

1. 單元測試

1.1 單元測試的意義

對於開發者而言，單元測試就是最基本的一種方式。若是開發者不本身測試代碼，那必然要面對以下問題。

1. 測試工程師是否可依賴？
2. 第三方代碼是否可依賴？
3. 在產品迭代過程當中，如何繼續保證質量？

編寫可測試代碼的原則：

• 單一職責
• 接口抽象
• 層次分離

對於開發者而言，不只要編寫單元測試，還應當編寫可測試代碼。

1.2 單元測試介紹

單元測試主要包括斷言、測試框架、測試用例、測試覆蓋率、mock、持續集成等方面。因爲Node的特殊性，還加入了異步代碼測試和私有方法的測試 。

1. 斷言

   斷言：單元測試中用來保證最小單元是否正常的監測方法。

   斷言用於檢查程序在運行時是否知足指望。

2. 測試框架

   記錄下拋出的異常並繼續執行，最後生成測試報告，這些任務的承擔者就是測試框架。

   測試框架用於測試服務，自己並不參與測試，主要用於管理測試用例和生成測試報告，提高測試用例的開發速度，提升測試用例的可維護性和可讀性，以及一些周邊性的工做。

   • 測試風格

     將測試用例的不一樣組織方式稱爲測試風格。

     主流的單元測試風格：

     • TDD(測試驅動開發)
     • BDD(行爲驅動開發)

     二者的差異：

     • 關注點不一樣。TDD關注全部的功能是否被正確實現，每個功能具有對應的測試用例；BDD關注總體行爲是否符合預期，適合自頂向下的設計方式。
     • 表達方式不一樣。TDD的表達方式偏向於功能說明書的風格；BDD的表述方式更接近於天然語言的習慣。

   • 測試報告

     不管採用哪一個斷言庫，運行測試用例後，測試報告是開發者和質量管理者都關注的東西。

3. 測試代碼的文件組織

   想讓單元測試順利運行起來，得在包描述文件(package.json)中添加相應模塊的依賴關係。

4. 測試用例

   一個行爲或者功能須要有完善的、多方面的測試用例，一個測試用例中包含至少一個斷言。

   測試用例最少須要經過正向測試和反向測試保證測試對功能的覆蓋，這是最基本的測試用例。

   • 異步測試

   • 超時設置

     若是一個測試用例的執行時間超過了預期時間，將會記錄下一個超時時間，而後執行下一個測試用例。

5. 測試覆蓋率

   經過不停地代碼添加測試用例，將會不斷地覆蓋代碼的分支和不一樣的狀況。

6. mock

   mock:經過僞造被調用方法來測試上層代碼的健壯性。

   經過模擬底層方法出現異常的狀況，只要監測調用方的輸出值是否符合指望便可，無須關注是否真正的異常。

7. 私有方法的測試

   rewire模塊提供了一種巧妙的方式實現對私有方法的訪問。

1.3 工程化與自動化

1. 工程化

   Node中使用Makefile來構建工程。

2. 持續集成

   對於實際的項目，頻繁地迭代是常態，如何記錄版本的迭代信息，還須要一個持續集成的環境。

   社區中流行的方式----利用travis實現持續集成。

2. 性能測試

性能測試的範疇較爲普遍，包括負載測試、壓力測試和基準測試。

2.1 基準測試

基準測試要統計的是在多少時間內執行了多少次某個方法。

2.2 壓力測試

對網絡接口進行壓力測試以判斷網絡接口的性能。

對網絡接口作壓力測試須要考察的指標有：吞吐率、響應時間和併發數。這些指標反映了服務器的併發處理能力。

2.3 基準測試驅動開發

基準測試驅動開發(BDD):

其流程：

1. 寫基準測試
2. 寫/改代碼
3. 收集數據
4. 找出問題
5. 回到第2步

2.4 測試數據與業務數據的轉換

在進行實際的功能開發前，須要評估業務量，以便開發完成後可以勝任實際的在線業務量。