《阿里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 層，Manager 層，可重用度高的 Service，都應該進行單元測試。

【推薦】編寫單元測試程式碼遵守 BCDE 原則，以保證被測試模組的交付質量。

• B：Border，邊界值測試，包括循環邊界、特殊取值、特殊時間點、資料順序等。
• C：Correct，正確的輸入，並得到預期的結果。
• D：Design，與設計文件相結合，來編寫單元測試。
• E：Error，強制錯誤訊息輸入(如：非法資料、異常流程、業務允許外等)，並得到預期的結果。

【推薦】對於資料庫相關的查詢，更新，刪除等操作，不能假設資料庫裡的資料是存在的，或者直接操作資料庫把資料插入進去，請使用程序插入或者導入資料的方式來準備資料。
反例：刪除某一行資料的單元測試，在資料庫中，先直接手動增加一行作為刪除目標，但是這一行新增資料並不符合業務插入規則，導致測試結果異常。

【推薦】和資料庫相關的單元測試，可以設定自動回滾機制，不給資料庫造成臟資料。或者對單元測試產生的資料有明確的前後綴標識。
正例：在阿里巴巴企業智能事業部的內部單元測試中，使用 ENTERPRISE_INTELLIGENCE _UNIT_TEST_ 的前綴來標識單元測試相關程式碼。

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

【推薦】在設計評審階段，開發人員需要和測試人員一起確定單元測試範圍，單元測試最好覆蓋所有測試用例(UC)。

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

【參考】為了更方便地進行單元測試，業務程式碼應避免以下情況：

• 構造方法中做的事情過多。
• 存在過多的全局變數和靜態方法。
• 存在過多的外部依賴。
• 存在過多的條件語句。

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

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

• 那是測試同學乾的事情。本文是開發手冊，凡是本文內容都是與開發同學強相關的。
• 單元測試程式碼是多餘的。系統的整體功能與各單元部件的測試正常與否是強相關的。
• 單元測試程式碼不需要維護。一年半載後，那麼單元測試幾乎處於廢棄狀態。
• 單元測試與線上故障沒有辯證關係。好的單元測試能夠最大限度地規避線上故障。

心得

看完這篇「單元測試」後，「測試」在開發過程中其實佔了非常重要的一環；良好完善的測試，可以在需求上線前先找到問題或是排除了很多可能性，而且開發過程中，往往會有很多盲點，但是透過測試可以找到本來未預期的狀況，然後去修改；特別注意，測試並不是只有在開發初期要建置和維護，在後續的再次開發或是修改，測試是要持續維護的。

另外如何做到自動化，目前有很多的CI/CD工作都整合的很完善，建議在專案開始初期就要把基礎建置用好，將來必定可以事半功倍。

結語

文章越看越多，技術越學越多，就會發現自己的不足；技術學到後面都會想要將基礎再重新在打得更加扎實。

以前在開發覺得理所當然的事情，例如：命名規則、命名規範，照著別人怎麼說就怎麼做的想法，並沒有好好去想為什麼要這樣設計和規範。
於是乎同事們推薦《阿里巴巴Java開發手冊》來做閱讀，書中提到種種規範《正確範例》、《錯誤範例》還有解釋定義說明；我相信在閱讀完這一系列後，一定會更加扎實且實在。

如對此書有興趣，建議去購買官方認證的書籍，給予官方支持。

註：如有侵權，通知即刪。

註：以上參考了
Alibaba-Java-Coding-Guidelines Github
Alibaba-Java-Coding-Guidelines English Version