讀《xUnit測試模式——測試碼重構》筆記

    因為產品的測試工程極不好用，又慢、又大、又亂、……關鍵是沒有哪個版本經理願意在測試代碼上耗費人力。偶然看到此書介紹，以為找到真經，跑到公司圖書館取來研讀。速速瀏覽一下，感覺遠遠沒有想象中管用，雖然封面也標明該書獲了美國生產力大獎，但和《敏捷式軟體開發 (Agile Software Development)原則、模式與實踐》相比不是一個檔次，we can't judge a book by its cover。內容大都熟悉，所以本書儘管很厚，沒有讓人拍案叫絕之處。中文翻譯我不滿意，太生硬，不少關鍵術語都不是研發一線的慣用語（例如“新鮮夾具”），  直接讀英文不比中文難讀。
xUnit.Test.Patterns.Refactoring.Test.Code.May.2007 

1、Setup方法的濫用

xUnit提供了Setup方法，有的初學者不知道有這麼個好東西，有的知道了但沒有將測試方法合理地分組就拿來用，效果不好。

本書打了個比方：“如果有了鎚子，什麼東西看起來都像是釘子！”

除了Setup，類似的還有mock。Mock是個好東西，但是如果你看到一個測試案例使用了25個mocker(…)，會有什麼感覺？這是我在我們產品測試代碼中見過的真執行個體子，思索了5秒後我把那個測試案例直接注掉了。

    還有一個值得一提的例子就是物件導向中的繼承，初學繼承者往往什麼都想重用。

    可謂“少年不知愁滋味，為賦新詞強說愁。”

 

2、如何減少測試碼複製？

經常看到一段段相似的測試案例，顯然是copy-paste的，特別是在結果驗證那幾行。有這麼幾招可以消除重複：

使用預期對象；

自訂斷言；

封裝驗證方法；

參數化和資料驅動；

 

3、如何編寫意圖明顯的測試碼？

寫產品代碼前先寫測試碼；

寫測試碼時先寫斷言；

標識符命名要明確體現意圖；

 

4、提倡每個測實驗證一種條件的原因是方便定位。

5、如何設計測試案例類？

三種方法：

（1）      
每個類（模組）一個測試案例類；

（2）      
每種特徵一個測試案例類；

（好處是易於理解業務情境，使用合適的命名）；

（3）      
每個前置條件一個測試案例類；

（利於將前置條件放到Setup方法，但又不濫用Setup。）

 

以上，沒有最好，只有最合適。

“最佳實務就是最適合於特定環境的實踐。”

 

6、關於代碼的壞味道

味道1：長測試

難以理解和維護，不能充當文檔角色。

導致長測試的典型原因：

（1）      
職責不單一。驗這驗那，驗太多功能。

（2）      
有神秘訪客。前置條件與驗證邏輯的因果關係不直觀、不明顯，依賴於神秘的外部資源（如檔案）。

（3）      
過多的前置條件。

（4）      
在讀者關心的層次放置了不相關的資訊（變數、值）；

（5）      
硬式編碼值；

（6）      
間接測試；

 

味道2：難以測試的代碼

如GUI、多任務、報文等。

對於高耦合的代碼，建議用mock解決。

對於任務體代碼，建議封裝任務體代碼，對封裝不分進行測試。

 

味道3：測試碼複製

味道4：產品中的測試邏輯

   

7、關於行為的壞味道

 

味道1：一個測試方法內堆積多個斷言，減少用例的數量

味道2：不穩定的測試，有時成功，有時失敗

原因可能是測試間相互耦合，共用條件，或自身狀態遷移。

味道3：手動調試，如單步跟蹤，看記憶體

味道4：緩慢

    原因：編譯慢、測試分類或標頭檔依賴不合理導致不必要的聯動、延時、大資料拷貝。

影響明顯直接徒增成本，降低團隊生產率。

 

8、項目的壞味道

味道1：開發人員不DT

時間緊：無暇顧及測試重構；

技能不足：測試設計及TDD經驗欠缺；

味道2：搞維護成本

    表面戰鬥力、覆蓋率上升，實際團隊生產率下降，耗費大量精力。

味道3：補用例

為什麼不安排在項目前期先寫用例？

味道4：用#if 0大量注掉難以維護的用例

    這些難以維護的用例大多是補出來的。

味道4：轉測試後發現本可通過LLT輕易發現的缺陷