單元測試檢查清單：讓你的測試保持有效，避免大的錯誤【已翻譯100%】

單元測試是測試你程式碼的一些常用方法集. 一般的操作步驟如下:

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”，比如只有在一些邊緣情況下，像等待通知或基於時鐘的方法。