Like Share Discussion Bookmark Smile

J.J. Huang   2020-05-11   Java   瀏覽次數:

《阿里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