4. 【強制】單元測試是可以重復執行的，不能受到外界環境的影響。
說明：單元測試通常會被放到持續集成中，每次有代碼 check in 時單元測試都會被執行。如果單測對外部
環境（網絡、服務、中間件等）有依賴，容易導致持續集成機制的不可用。
正例：為了不受外界環境影響，要求設計代碼時就把 SUT 的依賴改成注入，在測試時用 spring 這樣的 DI
框架注入一個本地（內存）實現或者 Mock 實現。
被測系統
被測系統(System under test, SUT)表示正在被測試的系統, 目的是測試系統能否正確操作.
根據測試類型的不同, SUT 指代的內容也不同, 例如 SUT 可以是一個類甚至是一整個系統.
6. 【強制】
核心業務、核心應用、核心模塊的增量代碼確保單元測試通過。
說明：新增代碼及時補充單元測試，如果新增代碼影響了原有單元測試，請及時修正。
7. 【強制】單元測試代碼必須寫在如下工程目錄：src/test/java，不允許寫在業務代碼目錄下。
說明：源碼編譯時會跳過此目錄，而單元測試框架默認是掃描此目錄。
8. 【推薦】單元測試的基本目標：語句覆蓋率達到 70%；核心模塊的語句覆蓋率和分支覆蓋率
都要達到 100%
說明：在工程規約的應用分層中提到的 DAO 層，Manager 層，可重用度高的 Service，都應該進行單元
測試。
分支覆蓋率 ：5個分支，那么對應的應該有10條語句（一個分支有兩條語句，ture和false），如果你執行了其中的5條，那么覆蓋率就是50%
11.【推薦】和數據庫相關的單元測試，可以設定自動回滾機制，不給數據庫造成臟數據。或者
對單元測試產生的數據有明確的前后綴標識。
正例：在企業智能事業部的內部單元測試中，使用 ENTERPRISE_INTELLIGENCE _UNIT_TEST_的前綴來
標識單元測試相關代碼。
15.【參考】為了更方便地進行單元測試，業務代碼應避免以下情況：
⚫ 構造方法中做的事情過多。
⚫ 存在過多的全局變量和靜態方法。
⚫ 存在過多的外部依賴。
⚫ 存在過多的條件語句。
說明：多層條件語句建議使用衛語句、策略模式、狀態模式等方式重構。
原文鏈接：https://blog.csdn.net/ljl86400/article/details/79885093
如果條件語句極其復雜，就應該將條件語句拆解開，然后逐個檢查，並在條件為真時立刻從函數中返回，這樣的單獨檢查通常被稱之為“衛語句”（guard clauses）
摘自《重構---改善既有代碼的設計》
衛語句的效果就是將原來需要仔細閱讀代碼、細心整理邏輯的條件判斷整理成一眼能看透的邏輯關系，效果就像以下：
if（obj != null）{
doSomething();
}
轉換成衛語句以后的代碼如下：
if(obj == null){
return;
}
doSomething();
16.【參考】不要對單元測試存在如下誤解：
⚫ 那是測試同學干的事情。本文是開發手冊，凡是本文內容都是與開發同學強相關的。
⚫ 單元測試代碼是多余的。系統的整體功能與各單元部件的測試正常與否是強相關的。
⚫ 單元測試代碼不需要維護。一年半載后，那么單元測試幾乎處於廢棄狀態。
⚫ 單元測試與線上故障沒有辯證關系。
好的單元測試能夠最大限度地規避線上故障。