老李分享：單元測試檢查清單：讓測試有效，避免致命錯誤 老李分享：單元測試檢查清單：讓測試有效，避免致命錯誤

老李分享：單元測試檢查清單：讓測試有效，避免致命錯誤

 

單元測試是測試你代碼的一些經常使用方法集. 通常的操做步驟以下:

1. 先寫北側類的API

2. 測試對應API的方法名

3. 實現對應測試API的方法體

4. 運行單元測試

爲何須要單元測試? 它能夠測試現有的以及將來的功能模塊. 保證代碼質量. 它規範你書寫具備可測性，低耦合的代碼.這比手工迴歸測試廉價的多. 它將提升代碼可行度.協助團隊工做.

爲啥須要個檢查列表? 單元測試在實際操做時可能要複雜一點. 它須要你考慮清楚整個待測對象的框架. 但測試自己應該簡單，直接，易用和易維護. 對於測試的開始點和結束點也要十分清楚.

使用這個檢查列表能幫助你確保測試範圍的有效性. 切記: 該列表能幫助你繞開那些明顯的錯誤，但有前提:

□  一個測試類對應一個被測類.

• o  你要測試的是一個已聲明的類的正確性.

□  一次只測試一個方法體.

• o  私有方法不須要測試! 它們是被封裝起來的.

□  測試的方法名和變量都是顯示定義的.

• o  好比，將預期結果保存到 expectedFoo 變量就比 foo好得多. 若是要測試不少複合結果，能夠使用組合的名稱inputValue_NotNull, inputValue_ZeroData, inputValue_PastDate, etc. (取決於你的代碼規範).

□  測試用例易於理解.

• o 後來的使用者將會很容易理解測試代碼的大意而無需關注太多的具體實現. 這能幫助他們在調試以前知道工做的大概內容.

 

□  測試用例符合代碼整潔規範.

• o  測試用例中不要包含流程控制語句 (switch, if, 等.). 好的用例就是很直接的數據準備，結果驗證過程.若是場景須要，能夠配上測試樁來優化代碼結構. 對於多場景測試，書寫多個對應的測試用例 (一一對應).

• o  好比，一個測試用例代碼長度最好在 – 1 到20行左右.若是測試代碼太長，考慮拆開成獨立的小測試集，以免攪在一塊兒.

□  測試用例最好驗證預期的異常.

• o  Java裏用 @Test(expected=MyException.class).

□  測試用例最好不要鏈接到數據庫.

• o或者說，若是測試中須要鏈接數據庫操做,就使用mock 「在每次新的測試開始注意測試時的數據庫鏈接狀態」鏈接，斷開  (使用 Setup/Teardown).

□  測試用例最好不要鏈接網絡資源.

• o 測試某個方法時沒辦法確保第三方的網絡設備的有效性 (使用mocks).

□  測試用例須要注意邊際效應,極限值 (max, min) 和null的處理(就算是在異常中拋出的也要注意).

• o就算在測試裏這些內容不須要被維護，咱們也要確保這些問題不會出現.

□ 測試用例不論在任什麼時候候任何地方都無需人工干預來執行.

□  測試用例測試了當前的代碼但也能很容易的測試未來實現的代碼.

• o  測試就是爲了確保代碼的正確演變.若是無法易於擴展，那它就成了負擔. (不少人不寫單元測試用例就是這個緣由.)

□  測試用例具備一致性.

• o  在Java: 別使用 Date()做爲被測方法的輸入數據，最好使用Calendar (別忘了時區配置). 再好比: 用name = 「Smith」; 不要用 name = 「name」; 或是name = 「test」;

□  測試用例使用mock來模擬複雜的代碼結構或方法體.

• o  記住一次只測試一個類.

  o  不要在本身的類中測試第三方的類庫. 類庫的測試交給它們本身的測試 (這也是鑑別類庫優劣的一條準則).

□  不要註釋掉測試用例 @ignored . 切記. 切記.

□  測試幫助我確保了總體的架構設計.

• o  若是有那個方法沒辦法被測試，說明設計的有問題.

□ 個人測試能夠運行在任何平臺，而非指定目標平臺

• 別期望一個特定的設備或硬件配置。不然你的測試會使遷移更困難，這裏鼓勵禁用它們。

□ 個人測試像閃電通常快！

• 慢的測試不該該把你拖垮。速度鼓勵你常常啓動您的測試。它還有助於減小持續集成系統上的構建時間。

• 使用測試運行程序，容許您在寫測試時一次啓動一個測試。要當心使用「delay」和「sleep」，好比只有在一些邊緣狀況下，像等待通知或基於時鐘的方法。