單元測試檢查清單：讓你的測試保持有效，避免大的錯誤
單元測試是測試你代碼的一些常用方法集. 一般的操作步驟如下:
-
先寫北側類的API
-
測試對應API的方法名
-
實現對應測試API的方法體
-
運行單元測試
為什么需要單元測試? 它可以測試現有的以及未來的功能模塊. 保證代碼質量. 它規范你書寫具有可測性，低耦合的代碼.這比手工回歸測試廉價的多. 它將提高代碼可行度.協助團隊工作.
為啥需要個檢查列表? 單元測試在實際操作時可能要復雜一點. 它需要你考慮清楚整個待測對象的框架. 但測試本身應該簡單，直接，易用和易維護. 對于測試的開始點和結束點也要十分清楚.
使用這個檢查列表能幫助你確保測試范圍的有效性. 切記: 該列表能幫助你繞開那些明顯的錯誤，但有前提:
□ 一個測試類對應一個被測類.
-
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”，比如只有在一些邊緣情況下，像等待通知或基于時鐘的方法。