1. 【強制】好的單元測試必須遵守 AIR 原則。
說明：單元測試在線上運行時，感覺像空氣 （AIR） 一樣並不存在，但在測試質量的保障上，卻是非常關鍵的。好的單元測試宏觀上來說，具有自動化、獨立性、可重複執行的特點。
A： Automatic （自動化）
I： Independent （獨立性）
R： Repeatable （可重複）
2. 【強制】單元測試應該是全自動執行的，並且非交互式的。測試框架通常是定期執行的，執行過程必須完全自動化才有意義。輸出結果需要人工檢查的測試不是一個好的單元測試。單元測試中不準使用 System.out 來進行人肉驗證，必須使用 assert 來驗證。
3. 【強制】保持單元測試的獨立性。為了保證單元測試穩定可靠且便於維護，單元測試用例之間決不能互相調用，也不能依賴執行的先後次序。
反例： method2 需要依賴 method1 的執行，將執行結果做為 method2 的輸入。
4. 【強制】單元測試是可以重複執行的，不能受到外界環境的影響。
說明：單元測試通常會被放到持續集成中，每次有代碼 check in 時單元測試都會被執行。如果單測對外部環境（網絡、服務、中間件等）有依賴，容易導致持續集成機制的不可用。
正例：為了不受外界環境影響，要求設計代碼時就把 SUT 的依賴改成注入，在測試時用 spring這樣的 DI 框架注入一個本地（內存）實現或者 Mock 實現。
5. 【強制】對於單元測試，要保證測試粒度足夠小，有助於精確定位問題。單測粒度至多是類級別，一般是方法級別。
說明：只有測試粒度小才能在出錯時儘快定位到出錯位置。單測不負責檢查跨類或者跨系統的交互邏輯，那是集成測試的領域。
6. 【強制】核心業務、核心應用、核心模塊的增量代碼確保單元測試通過。
說明：新增代碼及時補充單元測試，如果新增代碼影響了原有單元測試，請及時修正。
7. 【強制】單元測試代碼必須寫在如下工程目錄： src/test/java ，不允許寫在業務代碼目錄下。
說明：源碼構建時會跳過此目錄，而單元測試框架默認是掃描此目錄。
8. 【推薦】單元測試的基本目標：語句覆蓋率達到 70% ；核心模塊的語句覆蓋率和分支覆蓋率都要達到 100%
說明：在工程規約的應用分層中提到的 DAO 層， Manager 層，可重用度高的 Service ，都應該進行單元測試。
9. 【推薦】編寫單元測試代碼遵守 BCDE 原則，以保證被測試模塊的交付質量。
B： Border ，邊界值測試，包括循環邊界、特殊取值、特殊時間點、數據順序等。
C： Correct ，正確的輸入，並得到預期的結果。
D： Design ，與設計文檔相結合，來編寫單元測試。
E： Error ，強制錯誤信息輸入（如：非法數據、異常流程、非業務允許輸入等），並得到預期的結果。
10. 【推薦】對於數據庫相關的查詢，更新，刪除等操作，不能假設數據庫裡的數據是存在的，或者直接操作數據庫把數據插入進去，請使用程序插入或者導入數據的方式來準備數據。
反例：刪除某一行數據的單元測試，在數據庫中，先直接手動增加一行作為刪除目標，但是這一行新增數據並不符合業務插入規則，導致測試結果異常。
11. 【推薦】和數據庫相關的單元測試，可以設定自動回滾機制，不給數據庫造成髒數據。或者對單元測試產生的數據有明確的前後綴標識。
正例：在 RDC 內部單元測試中，使用 RDC_UNIT_TEST_ 的前綴標識數據。
12. 【推薦】對於不可測的代碼建議做必要的重構，使代碼變得可測，避免為了達到測試要求而書寫不規範測試代碼。
13. 【推薦】在設計評審階段，開發人員需要和測試人員一起確定單元測試範圍，單元測試最好覆蓋所有測試用例（ UC ）。
14. 【推薦】單元測試作為一種質量保障手段，不建議項目發佈後補充單元測試用例，建議在項目提測前完成單元測試。
15. 【參考】為了更方便地進行單元測試，業務代碼應避免以下情況：
構造方法中做的事情過多。
存在過多的全局變量和靜態方法。
存在過多的外部依賴。
存在過多的條件語句。
說明：多層條件語句建議使用衛語句、策略模式、狀態模式等方式重構。
16. 【參考】不要對單元測試存在如下誤解：
那是測試同學乾的事情。本文是開發手冊，凡是本文內容都是與開發同學強相關的。
單元測試代碼是多餘的。汽車的整體功能與各單元部件的測試正常與否是強相關的。
單元測試代碼不需要維護。一年半載後，那麼單元測試幾乎處於廢棄狀態。
單元測試與線上故障沒有辯證關係。好的單元測試能夠最大限度地規避線上故障。
有討論，才有進步，大家各抒己見，讓每位同學學到不一樣的！
閱讀更多 Free碼農 的文章
