單元測試 AIR 原則

單元測試 AIR 原則

好的單元測試必須遵照 AIR 原則，即 Automatic(自動化)、Independent(獨立性)、Repeatable(可重複)。

Automatic(自動化)

單元測試應該是全自動執行的，而且非交互式的。測試用例一般是被按期執行的，執行過程必須徹底自動化纔有意義。輸出結果須要人工檢查的測試不是一個好的單元測試。單元 測試中不許使用 System.out 來進行人肉驗證，必須使用 assert 來驗證。

Independent(獨立性)

保持單元測試的獨立性。爲了保證單元測試穩定可靠且便於維護，單元測試用例之間決不能互相調用，也不能依賴執行的前後次序。

Repeatable(可重複)

單元測試是能夠重複執行的，不能受到外界環境的影響。由於單元測試一般會被放到持續集成中，每次有代碼 check in時單元測試都會被執行。若是單測對外部環境（網絡、服務、中間件等）有依賴，容易致使持續集成機制的不可用。

爲了避免受外界環境影響，要求設計代碼時就把 SUT 的依賴改爲注入，在測試時用 spring這樣的 DI 框架注入一個本地（內存）實現或者 Mock 實現。

單元測試粒度

對於單元測試，要保證測試粒度足夠小，有助於精肯定位問題。單測粒度至可能是類級別，通常是方法級別。只有測試粒度小才能在出錯時儘快定位到出錯位置。單測不負責檢查跨類或者跨系統的交互邏輯，那是集成測試的領域。

單元測試範圍

核心業務、核心應用、核心模塊的增量代碼確保單元測試經過。新增代碼及時補充單元測試，若是新增代碼影響了原有單元測試，請及時修正。

其它規範

一、單元測試代碼必須寫在以下工程目錄 src/test/java，不容許寫在業務代碼目錄下。

二、單元測試的基本目標:語句覆蓋率達到 70%;核心模塊的語句覆蓋率和分支覆蓋率都要達到 100%。

三、在工程規約的應用分層中提到的 DAO 層，Manager 層，可重用度高的 Service，都應該進行單元測試。

四、編寫單元測試代碼遵照 BCDE 原則，以保證被測試模塊的交付質量。

阿里巴巴 Java 開發手冊 \9. 【推薦】編寫單元測試代碼遵照 BCDE 原則，以保證被測試模塊的交付質量。

• Border：邊界值測試，包括循環邊界、特殊取值、特殊時間點、數據順序等；

• Correct：正確的輸入，並獲得預期的結果；

• Design：與設計文檔相結合，來編寫單元測試；

• Error：強制錯誤信息輸入（如:非法數據、異常流程、非業務容許輸入等），並獲得預期的結果；

五、對於數據庫相關的查詢，更新，刪除等操做，不能假設數據庫裏的數據是存在的， 或者直接操做數據庫把數據插入進去，請使用程序插入或者導入數據的方式來準備數據。

六、和數據庫相關的單元測試，能夠設定自動回滾機制，不給數據庫形成髒數據。或者 對單元測試產生的數據有明確的先後綴標識。

七、對於不可測的代碼建議作必要的重構，使代碼變得可測，避免爲了達到測試要求而書寫不規範測試代碼。

八、在設計評審階段，開發人員須要和測試人員一塊兒肯定單元測試範圍，單元測試最好覆蓋全部測試用例。

九、單元測試做爲一種質量保障手段，不建議項目發佈後補充單元測試用例，建議在項目提測前完成單元測試。

十、爲了更方便地進行單元測試，業務代碼應避免如下狀況：

• 構造方法中作的事情過多

• 存在過多的全局變量和靜態方法

• 存在過多的外部依賴

• 存在過多的條件語句。說明:多層條件語句建議使用衛語句、策略模式、狀態模式等方式重構

十一、不要對單元測試存在以下誤解：

• 那是測試同窗乾的事情
• 單元測試代碼是多餘的。系統的總體功能與各單元部件的測試正常與否是強相關的
• 單元測試代碼不須要維護，一年半載後，那麼單元測試幾乎處於廢棄狀態
• 單元測試與線上故障沒有辯證關係，好的單元測試可以最大限度地規避線上故障