一、理論上的原則如下
<bdo id='0WhNG'></bdo><ul id='6FKuh'></ul>
- 快：單元測試是回歸測試，可以在開發過程的任何時候運行，因此運行速度必須快。
- 一致性：代碼沒有改變的情況下，每次運行得結果應該保持確定且一致。
- 原子性：結果只有兩種情況：Pass / Fail。
- 用例獨立：執行順序不影響；用例間沒有狀態共享或者依賴關系；用例沒有副作用（執行前后環境狀態一致）。
- 單一職責：一個用例只負責一個場景。
- 隔離：功能可能依賴于數據庫、web訪問、環境變量、系統時間等；一個單元可能依賴于另一部分代碼，用例應該解除這些依賴。
- 可讀性：用例的名稱、變量名等應該具有可讀性，直接表現出該測試的目標。
- 自動化：單元測試需要全自動執行。測試程序不應該有用戶輸入；測試結果應該能直接被電腦獲取，不應該由人來判斷。
二、規范原則
在實際編寫代碼過程中，不同的團隊會有不同團隊的風格，只要團隊內部保持有一定的規范即可，比如：
- 單元測試文件名必須以xxx_test.go命名。
- 方法必須是TestXxx開頭，建議風格保持一致（駝峰或者下劃線）。
- 方法參數必須 t *testing.T。
- 測試文件和被測試文件必須在一個包中。
三、衡量原則
單元測試是要寫額外的代碼的，這對開發同學的也是一個不小的工作負擔，在一些項目中，需要合理的評估單元測試的編寫，個人認為我們不能走極端，當然理論上來說全都寫是好的，但是從成本，效率上來說我們必須做出權衡，衡量原則有：
- 優先編寫核心組件和邏輯模塊的測試用例。
- 邏輯類似的組件如果存在多個，優先編寫其中一種邏輯組件的測試用例。
- 發現Bug時一定先編寫測試用例進行Debug。
- 關鍵util工具類要編寫測試用例，這些util工具適用的很頻繁，所以這個原則也叫做熱點原則，和第1點相呼應。
- 測試用戶應該獨立，一個文件對應一個，不同的測試用例之間不要互相依賴。
- 測試用例保持更新。
