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,然後測試的項目,就會越來越齊全...,也會越有成就感。



參考:


留言

  1. 「大於 80% 的 code coverage,單元測試的效能會符合收益遞減率 」
    他的意思應該是超過 80% 在時間成本上就不合算了,
    我們期望花少許時間就可以抓出「大部份 」的 bug,而不是「全部的」 bug 。

    像我以前就會花很多時間去把 code coverage 拼到 100% ,滿足一下自己的虛榮心 XD
    但後來想想那真的不代表什麼, coverage 100% 不代表沒 bug

    回覆刪除
    回覆
    1. "收益遞減率" 是經濟學的專有名詞,一般經濟學的書裡面比較常看到的名詞是 "邊際報酬遞減",比較簡單的解釋是:產品的生產量會隨著人力的增加而增加,但到了一定的限度後,產量(邊際產量) 的增加率會呈現遞減的現象

      刪除
    2. 謝謝 @cash wu 整個是太專業了 !

      刪除
  2. 一個經濟學的概念...XD

    回覆刪除
    回覆
    1. 真的.. 最近看書看得好累就是這樣,涉及好多門領域的世界,害我好挫折哦 QQ

      刪除

張貼留言

若你看的文章,時間太久遠的問題就別問了,因為我應該也忘了... XD

這個網誌中的熱門文章

[Android] 筆記 手機上測試自己的 APP

解決fatal: Not a git repository (or any of the parent directories): .git錯誤

[Android 筆記] 設定 ImageView 的圖檔來源