單元測試

所有内容摘自阿裡巴巴的《java開發手冊-嵩山版》

【強制】好的單元測試必須遵守 air 原則。說明：單元測試線上上運作時，感覺像空氣（air）一樣感覺不到，但在測試品質的保障上，卻是非常關鍵的。好的單元測試宏觀上來說，具有自動化、獨立性、可重複執行的特點。

a：automatic（自動化）

i：independent（獨立性）

r：repeatable（可重複）

【強制】單元測試應該是全自動執行的，并且非互動式的。測試用例通常是被定期執行的，執行過程必須完全自動化才有意義。輸出結果需要人工檢查的測試不是一個好的單元測試。單元測試中不準使用 system.out 來進行人肉驗證，必須使用 assert 來驗證。

【強制】儲存單元測試的獨立性。為了保證單元測試穩定可靠并且便于維護，單元測試用例之間絕不能互相調用，也不能依賴執行的先後次序。

反例：method2 需要依賴 method1 的執行，将執行結果作為 method2 的輸入。

【強制】單元測試是可以重複執行的，不能收到外界環境的影響。

說明：單元測試通常會被放到持續內建中，每次有代碼 check in 時單元測試都會被執行。如果單元測試對外部環境（網絡、服務、中間件等）有依賴，容易造成持續內建機制的不可用。

正例：為了不受外界環境影響，要求設計代碼時就把 sut 的依賴改成注入，在測試時 spring 這樣的 di 架構注入一個本地（記憶體）實作或者 mock 實作。

【強制】對于單元測試，要保證測試粒度足夠小，有助于精确定位問題。單測粒度至多是類級别，一般是方法級别。

說明：隻有測試粒度小才能在出錯時盡快定位到出錯位置。單測不負責檢查跨類或者跨系統的互動邏輯，那是內建測試的領域。

【強制】核心業務、核心應用、核心子產品的增量代碼確定單元測試通過。

說明：新增代碼及時補充單元測試，如果新增代碼影響了原有測試，請及時修正。

【強制】單元測試代碼必須寫在如下工程目錄：src/test/java，不允許寫在業務代碼目錄下。

說明：源碼編譯時會跳過此目錄，而單元測試架構預設是掃描此目錄。

【推薦】單元測試的基本目标：語句覆寫率達到 70%；核心子產品的語句覆寫率和分支覆寫率都要達到 100%。

說明：在工程規約的應用分層中提到的 dao 層，mapper 層，可用度高的 service 層，都應該進行單元測試。

【推薦】編寫單元測試代碼遵守 bcde 原則，以保證被測試子產品的傳遞品質。

b：border，邊界值測試，包括循環邊界、特殊取值、特殊時間點、資料順序等。

c：correct，正确的輸入，并得到預期的結果。

d：design，與設計文檔相結合，來編寫單元測試。

e：error，強制錯誤資訊輸入（如：非法資料、異常流程、業務允許外等），并得到預期的結果。

【推薦】對于資料庫相關的查詢，更新，删除等操作，不能假設資料庫裡的資料是存在的，或者直接操作資料庫把資料插入進去，請使用程式插入或者導入資料的方式來準備資料。

反例：删除某一行資料的單元測試，在資料庫中，先直接手動增加一行作為删除目标，但是這一行新增資料并不符合業務插入規則，導緻測試結果異常。

【推薦】和資料庫相關的單元測試，可以設定自動復原機制，不給資料庫造成髒資料。或者對單元測試産生的資料有明确的前字尾辨別。

正例：在阿裡巴巴企業智能事業部的内部單元測試中，使用 enterprise_intelligence_unit_test_ 的字首來辨別單元測試相關代碼。

【推薦】對于不可測的代碼在适當的時機做必要的重構，使代碼變得可測，避免為了達到測試要求而書寫不規範測試代碼。

【推薦】在設計評審階段，開發人員需要和測試人員一起确定單元測試範圍，單元測試最好覆寫所有測試用例（uc）。

【推薦】單元測試作為一種品質保障手段，在項目提測前完成單元測試，不建議項目釋出後補充單元測試用例。

【參考】為了更友善的進行單元測試，業務代碼應避免以下情況：

構造方法中做的事情過多。

存在過多的全局變量和靜态方法。

存在過多的外部依賴。

存在過多的條件語句。

說明：多層條件語句建議使用衛語句、政策模式、狀态模式等方式重構。

【參考】不要對單元測試存在如下誤解：

那是測試同學幹的事情。本文是開發手冊，凡是本文内容都是與開發同學強相關的。

單元測試代碼是多餘的。系統的整體功能與各單元部件的測試正常與否是強相關的。

單元測試代碼不需要維護。一年半載後，那麼單元測試幾乎處于廢棄狀态。

單元測試與線上故障沒有辨證關系。好的單元測試能夠最大限度地避免線上故障。