單元測試不規範！過後運維兩行淚

這是我參與更文挑戰的第28天，活動詳情查看：更文挑戰

單元測試

• 好的單元測試應該遵照AIR原則
  • 單元測試在線上運行時,應該感受像空氣(AIR)同樣,並不存在,但在測試質量的保障上,確實很是關鍵的
  • 好的單元測試宏觀上來講,具有如下的特色:
    • 自動化(A: Automatic)
    • 獨立性(I: Independent)
    • 可重複(R: Repeatable)
• 單元測試應該是全自動執行的,而且是非交互式的
  • 測試用例一般是被按期執行的,執行過程必須徹底自動化纔有意義
  • 輸出結果須要人工檢查的測試不是一個好的單元測試
  • 單元測試中不許使用System.out來進行人的驗證,必須使用assert來驗證
• 保持單元測試的獨立性
  • 爲了保證單元測試穩定可靠且便於維護:
    • 單元測試用例之間決不能互相調用
    • 不能依賴執行的前後次序
• 單元測試是能夠重複執行的,不能受到外界環境的影響
  • 單元測試一般會被放到持續集成中,每次代碼有check in時單元測試都會被執行
    • 若是對外部環境(網絡,服務,中間件等)有依賴,容易致使集成機制不可用
  • 爲了避免受外界環境的影響,要求設計代碼時就把SUT的依賴改爲注入
  • 在測試時用spring這樣的DI框架注入一個本地(內存)實現或者Mock實現
• 對於單元測試,要保證測試粒度足夠小,有助於精肯定位問題,單元測試粒度至可能是類級別,一般是方法級別的
  • 只有測試粒度小才能在出錯時儘快定位到出錯位置
  • 單元測試不負責檢查跨類或者跨系統的交互邏輯,那是集成測試的領域
• 核心業務,核心應用,核心模塊的增量代碼確保單元測試經過
  • 新增代碼及時補充單元測試
  • 若是新增代碼影響了原有代碼,確保及時修正
• 單元測試代碼必須寫在以下工程目錄中 :src/test/java, 不容許寫在業務代碼目錄下
  • 源碼構建會跳過此目錄,而單元測試框架默認掃描此目錄
• 單元測試的基本目標:
  • 語句覆蓋率達到70%
  • 核心模塊語句覆蓋率和分支覆蓋率都要達到100%
  • 在工程規約的應用分層中提到的DAO層 ,Manager層,可重用度高的Service, 都應該進行單元測試
• 編寫單元測試代碼要遵照BCDE規則,以確保被測試模塊交付質量:
  • B: Border ,邊界值測試, 包括循環邊界,特殊取值,特殊時間點,數據順序等
  • C: Correct ,正確的輸入,並獲得預期的結果
  • D: Design ,與設計文檔相結合, 來編寫單元測試
  • E: Error ,強制錯誤信息輸入, 好比非法數據,異常流程,非業務容許輸入,並獲得預期的結果
• 對於數據庫的查詢,更新,刪除等操做:
  • 不能夠假設數據庫裏的數據是存在的
  • 不能夠直接操做數據庫將數據插入進去
  • 必須使用程序插入或者導入數據的方式來準備數據
• 和數據庫相關的單元測試,能夠設定自動回滾機制,不給數據庫形成髒數據,或者對單元測試產生的數據有明確的先後綴標識
  • 好比在RDC內部的單元測試中,使用RDC_UNIT_TEST_的前綴標識數據
• 對於不可測的代碼要作必要的重構,使代碼變得可測,避免爲了達到測試要求而書寫不規範的測試代碼
• 在設計評審階段,開發人員須要和測試人員一塊兒肯定單元測試範圍,單元測試最好覆蓋全部測試用例
• 單元測試做爲一種質量保障手段,不要在項目發佈後補充單元測試用例,須要在項目提測前完成單元測試
• 爲了更方便地進行單元測試,業務代碼須要避免如下狀況:
  • 構造方法中作的事情過多
  • 存在過多的全局變量和靜態方法
  • 存在過多的外部依賴
  • 存在過多的條件語句:
    • 多層條件語句建議使用衛語句,策略模式,狀態模式重構
• 不要對單元測試存在誤解:
  • 認爲單元測試是測試的事情
  • 認爲單元測試代碼是多餘的.系統總體功能與各個單元部件的測試正常與否是強相關的
  • 認爲單元測試代碼不須要維護.這樣會致使一段時間事後,單元測試幾乎處於廢棄的狀態
  • 認爲單元測試與線上故障沒有辯證關係.好的單元測試能最大限度地規避線上故障