二、單元測試 · 凡普金科開發規范

## 二、單元測試 1. 【強制】好的單元測試必須遵守AIR原則。 說明：單元測試在線上運行時，感覺像空氣（AIR）一樣并不存在，但在測試質量的保障上，卻是非常關鍵的。好的單元測試宏觀上來說，具有自動化、獨立性、可重復執行的特點。 - A：Automatic（自動化） - I：Independent（獨立性） - R：Repeatable（可重復） 2. 【強制】單元測試應該是全自動執行的，并且非交互式的。測試用例通常是被定期執行的，執行過程必須完全自動化才有意義。輸出結果需要人工檢查的測試不是一個好的單元測試。單元測試中不準使用System.out來進行人肉驗證，必須使用assert來驗證。 3. 【強制】保持單元測試的獨立性。為了保證單元測試穩定可靠且便于維護，單元測試用例之間決不能互相調用，也不能依賴執行的先后次序。 反例：method2需要依賴method1的執行，將執行結果作為method2的輸入。 4. 【強制】單元測試是可以重復執行的，不能受到外界環境的影響。 說明：單元測試通常會被放到持續集成中，每次有代碼check in時單元測試都會被執行。如果單測對外部環境（網絡、服務、中間件等）有依賴，容易導致持續集成機制的不可用。 正例：為了不受外界環境影響，要求設計代碼時就把SUT的依賴改成注入，在測試時用spring 這樣的DI框架注入一個本地（內存）實現或者Mock實現。 5. 【強制】對于單元測試，要保證測試粒度足夠小，有助于精確定位問題。單測粒度至多是類級別，一般是方法級別。 說明：只有測試粒度小才能在出錯時盡快定位到出錯位置。單測不負責檢查跨類或者跨系統的交互邏輯，那是集成測試的領域。 6. 【強制】核心業務、核心應用、核心模塊的增量代碼確保單元測試通過。 說明：新增代碼及時補充單元測試，如果新增代碼影響了原有單元測試，請及時修正。 7. 【強制】單元測試代碼必須寫在如下工程目錄：src/test/java，不允許寫在業務代碼目錄下。 說明：源碼構建時會跳過此目錄，而單元測試框架默認是掃描此目錄。 8. 【推薦】單元測試的基本目標：語句覆蓋率達到70%；核心模塊的語句覆蓋率和分支覆蓋率都要達到100% 說明：在工程規約的應用分層中提到的DAO層，Manager層，可重用度高的Service，都應該進行單元測試。 9. 【推薦】編寫單元測試代碼遵守BCDE原則，以保證被測試模塊的交付質量。 - B：Border，邊界值測試，包括循環邊界、特殊取值、特殊時間點、數據順序等。 - C：Correct，正確的輸入，并得到預期的結果。 - D：Design，與設計文檔相結合，來編寫單元測試。 - E：Error，強制錯誤信息輸入（如：非法數據、異常流程、非業務允許輸入等），并得到預期的結果。 10. 【推薦】對于數據庫相關的查詢，更新，刪除等操作，不能假設數據庫里的數據是存在的，或者直接操作數據庫把數據插入進去，請使用程序插入或者導入數據的方式來準備數據。 反例：刪除某一行數據的單元測試，在數據庫中，先直接手動增加一行作為刪除目標，但是這一行新增數據并不符合業務插入規則，導致測試結果異常。 11. 【推薦】和數據庫相關的單元測試，可以設定自動回滾機制，不給數據庫造成臟數據。或者對單元測試產生的數據有明確的前后綴標識。 正例：在RDC內部單元測試中，使用RDC_UNIT_TEST_的前綴標識數據。 12. 【推薦】對于不可測的代碼建議做必要的重構，使代碼變得可測，避免為了達到測試要求而書寫不規范測試代碼。 13. 【推薦】在設計評審階段，開發人員需要和測試人員一起確定單元測試范圍，單元測試最好覆蓋所有測試用例（UC）。 14. 【推薦】單元測試作為一種質量保障手段，不建議項目發布后補充單元測試用例，建議在項目提測前完成單元測試。 15. 【參考】為了更方便地進行單元測試，業務代碼應避免以下情況： - 構造方法中做的事情過多。 - 存在過多的全局變量和靜態方法。 - 存在過多的外部依賴。 - 存在過多的條件語句。 說明：多層條件語句建議使用衛語句、策略模式、狀態模式等方式重構。 16. 【參考】不要對單元測試存在如下誤解： - 那是測試同學干的事情。本文是開發手冊，凡是本文內容都是與開發同學強相關的。 - 單元測試代碼是多余的。汽車的整體功能與各單元部件的測試正常與否是強相關的。 - 單元測試代碼不需要維護。一年半載后，那么單元測試幾乎處于廢棄狀態。 - 單元測試與線上故障沒有辯證關系。好的單元測試能夠最大限度地規避線上故障。 ***** JUnit 4 單元測試舉例： Maven 的 pom.xml 文件中引入 JUnit 4 的依賴包。 ``` <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> <scope>test</scope> </dependency> ``` JUnit 4 示例代碼如下： ``` public class JUnit4DemonTest { @BeforeClass public static void initAll() { //TODO：測試類運行前初始化代碼 } @AfterClass public static void tearDownAll() { //TODO：測試類運行后清理代碼 } @Before public void init() { //TODO：測試方法運行前初始化代碼 } @After public void tearDown() { //TODO：測試方法運行后清理碼 } @Test public void succeedingTest() { //TODO：正面測試用例代碼 } @Test public void failingTest() { //TODO：負面測試用例代碼 } } ``` 下面是一段單元測試示例，必須要有assert斷言： ``` public class WhenCheckingMinimumStatusPoints { private FrequentFlyer member; @Before public void newFrequentFlyer() { member = FrequentFlyer("xiaoming"); } //測試新注冊用戶應該為銅牌會員 @Test public void should_have_bronze_status_initially() { assertEquals(FrequentFlyerStatus.BRONZE, member.getStatus()); assertThat(member.getStatus(), is(FrequentFlyerStatus.BRONZE)); } //測試常旅客購買機票可以累積積分 @Test public void should_cumulate_points_with_each_flight() { member.earns(100).statusPoints(); member.earns(200).statusPoints(); assertThat(member.getStatusPoints(),is(greaterThanOrEqualTo((300)))); assertThat(member.getStatus(), is(FrequentFlyerStatus.SILVER)); } //測試常旅客積分為300時應該為銀牌會員 @Test public void should_need_300_points_for_silver() { FrequentFlyerStatus status = FrequentFlyerStatus.statusLevelFor(300); assertThat(status, is(FrequentFlyerStatus.SILVER)); } } ```