O'REILLY『可測試的 JavaScript』 讀書心得

(我好幾次呆坐在螢幕前，不知道該分享些什麼...)

第一次在書店看到這本書時還蠻興奮的，又是 JavaScript，又講測試，感覺就應該讀一下，立刻帶回家 XD (敗家)。

幾個心得:

＊測試是有方法可以遵循，有經驗可以參考，但是寫測試是要練出來的，只有自己練出來才是最真實的...。

 *  TDD (Test-Driven Development) 測試驅動開發，是敏捷開發的推薦做法，就是先寫測試，再寫相對應的程式。 

 * BDD (Behavior-Driven Development) 行為驅動開發，建立在 TDD 之上，測試描述一個程式或是模組的行為。 

＊要測試你的程式碼，首先程式碼要先可以被測試才是重點，畢竟程式可以很複雜，也可以很簡單，可以測試的程式碼要盡量是低耦合, 獨立的。(多做程式的拆解練習，把複雜的程式慢慢拆解為一隻隻比較單純, 單一任務的程式)。

＊第三章講的事件導向架構，我沒有看得很懂就是，但是重點跟上一點接近。

＊第四章講單元測試，單元測試算是我第一次接觸測試的方式，他需要工程師去思考每個單元測試需要哪些測試案例(腦補一些可能出現的弱點，就好像某隻程式明明需要帶入一個 值為 email 的參數，但是只有測到這個參數帶進去，卻沒有測試 email 的格式是否正確之類的...)，因此，單元測試算是不能百分之百找到 bug 的測試，但是單元測試的重點是在於測試每隻程式的功能是否有符合需求(功能確認導向)。

   另外單元測試的 code 我覺得蠻好讀的，他的重點就是斷言(assert)，直接去驗證某個值是否符合預期。

* 程式碼涵蓋率(Code Coverage)，用來測量已經執行的測試程式碼之於未執行過的程式碼的涵蓋數，結果會用百分比來表示。 通常跟單元測試有關。書中 P.95 有個涵蓋率的參考:

    - 低於 50% 的 code coverage，是個低標區 (red flag)

    - 介於 60%~80% 的 code coverage，是甜蜜區 (sweet spot)

    - 大於 80% 的 code coverage，單元測試的效能會符合收益遞減率(<- 基本上我看不懂這個意思是什麼) ( code coverage 過高可能有誤導之嫌)。

   另外，code coverage 最好是自動化產生。

* 測試環境的模擬，也是一個很重要的測試技能。也許你在測試某隻程式時，需要重新設定資料庫的狀態，或是某隻程式可能相依於另一隻程式(相依性，是單元測試不想要測試的部分，可以利用 mocks 或是 stubs)。

*  mocks 跟 stubs 的不同在於 mocks 用於命令， stubs 用於查詢(參考 p.95)

  

*  mocks 用來被驗證 function 正確呼叫外部的 api。

*  stubs  用來假造回傳值到需要被測試的 function。

*  Doubles (測試替身)，用來模擬相依性所需要用的物件，他也可同時扮演 mock 或是 stub。

*  前端 JavaScript，可參考 PhantomJS, Selenium。因為這兩個，方向都很大，我也沒摸熟過，不方便提...

*  第六章講效能測試，瀏覽器效能測試可以參考 HAR，書中有說明如何產生 HAR 檔案，如何查看。負載測試(Load Testing)  最常聽到的就是 ab (Apache Bench)。

*  效能測試可以用來辨別會阻礙效能的瓶頸，負載測試用來測試程式可以處理多少事情。

最後，我是覺得剛接觸測試的話，可以翻翻這本書，但是不用帶著墨在書本範例的程式碼，概念上先瞭解一下，這本書用蠻多 YUI 的 code 來解說，大概看一下就好，只是像我這種沒用過 YUI 的人，會覺得有點失落 XDD，因為書本有時候會提到一些 solution 是針對 YUI 的解法，所以有時候也會蠻疑惑的 XD。

前陣子在工作上是使用 Mocha, Chai 寫測試，有空再來分享這一塊。

以前看到別人講測試會覺得有點複雜，工具太多，要測試的方法也很多，嘗試過 chai, mocha 之後我才漸漸了解，原來這些測試工具都是環環相扣的，而且很有可能會上癮，也許你單元測試寫完之後，你就會想了解 code coverage，然後你也會想要用一下 phantom 或是 selenium，然後測試的項目，就會越來越齊全...，也會越有成就感。

參考:

可測試的 JavaScript (O'Reilly)  ISBN：9789863470090。