《原神攻略》清籟舊憶拍照在哪拍？清籟舊憶拍照位置分享

阿新 • • 發佈：2021-09-08

所有內容摘自阿里巴巴的《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）。
【推薦】單元測試作為一種質量保障手段，在專案提測前完成單元測試，不建議專案釋出後補充單元測試用例。
【參考】為了更方便的進行單元測試，業務程式碼應避免以下情況：