Java單元測試框架PowerMock技巧

本文章轉自：樂字節

文章主要講解：PowerMock

獲取更多JAVA相關資料能夠關注公衆號《樂字節》 發送：999

前言

高德的技術大佬在談論方法論時說到：「複雜的問題要簡單化，簡單的問題要深刻化。」

這句話讓我感觸頗深，這未嘗不是一套編寫代碼的方法——把一個複雜邏輯拆分爲許多簡單邏輯，而後把每個簡單邏輯進行深刻實現，最後把這些簡單邏輯整合爲複雜邏輯，總結爲八字真言便是「化繁爲簡，由簡入繁」。

編寫Java單元測試用例，其實就是把「複雜的問題要簡單化」——即把一段複雜的代碼拆解成一系列簡單的單元測試用例；寫好Java單元測試用例，其實就是把「簡單的問題要深刻化」——即學習一套方法、總結一套模式並應用到實踐中。這裏，做者根據平常的工做經驗，總結了一些Java單元測試技巧，以供你們交流和學習。

1. 準備環境

PowerMock是一個擴展了其它如EasyMock等mock框架的、功能更增強大的框架。PowerMock使用一個自定義類加載器和字節碼操做來模擬靜態方法、構造方法、final類和方法、私有方法、去除靜態初始化器等等。

1.1. 引入PowerMock包

爲了引入PowerMock包，須要在pom.xml文件中加入下列maven依賴：

1.2. 集成SpringMVC項目

在SpringMVC項目中，須要在pom.xml文件中加入JUnit的maven依賴：

1.3. 集成SpringBoot項目

在SpringBoot項目中，須要在pom.xml文件中加入JUnit的maven依賴：

1.4. 一個簡單的測試用例

這裏，用List舉例，模擬一個不存在的列表，可是返回的列表大小爲100。

2. mock語句

2.1. mock方法

聲明：

T PowerMockito.mock(Class clazz);

用途：

能夠用於模擬指定類的對象實例。

當模擬非final類（接口、普通類、虛基類）的非final方法時，沒必要使用@RunWith和@PrepareForTest註解。當模擬final類或final方法時，必須使用@RunWith和@PrepareForTest註解。註解形如：

@RunWith(PowerMockRunner.class)

@PrepareForTest({TargetClass.class})

2.1.1. 模擬非final類普通方法

2.1.2. 模擬final類或final方法

2.2. mockStatic方法

聲明：

PowerMockito.mockStatic(Class clazz);

用途：

能夠用於模擬類的靜態方法，必須使用「@RunWith」和「@PrepareForTest」註解。

3. spy語句

若是一個對象，咱們只但願模擬它的部分方法，而但願其它方法跟原來同樣，可使用PowerMockito.spy方法代替PowerMockito.mock方法。因而，經過when語句設置過的方法，調用的是模擬方法；而沒有經過when語句設置的方法，調用的是原有方法。

3.1. spy類

聲明：

PowerMockito.spy(Class clazz)；

用途：

用於模擬類的部分方法。

案例：

3.2. spy對象

聲明：

T PowerMockito.spy(T object)；

用途：

用於模擬對象的部分方法。

案例：

4. when語句

4.1. when().thenReturn()模式

聲明：

用途：

用於模擬對象方法，先執行原始方法，再返回指望的值、異常、應答，或調用真實的方法。

4.1.1. 返回指望值

4.1.2. 返回指望異常

4.1.3. 返回指望應答

4.1.4. 調用真實方法

4.2. doReturn().when()模式

聲明：

用途：

用於模擬對象方法，直接返回指望的值、異常、應答，或調用真實的方法，無需執行原始方法。

注意：

千萬不要使用如下語法：

雖然不會出現編譯錯誤，可是在執行時會拋出UnfinishedStubbingException異常。

4.2.1. 返回指望值

4.2.2. 返回指望異常

4.2.3. 返回指望應答

4.2.4. 模擬無返回值

4.2.5. 調用真實方法

4.3. 兩種模式的主要區別

兩種模式都用於模擬對象方法，在mock實例下使用時，基本上是沒有差異的。可是，在spy實例下使用時，when().thenReturn()模式會執行原方法，而doReturn().when()模式不會執行原方法。

測試服務類：

使用when().thenReturn()模式：

在測試過程當中，將會打印出"調用獲取用戶數量方法"日誌。

使用doReturn().when()模式：

在測試過程當中，不會打印出"調用獲取用戶數量方法"日誌。

4.4. whenNew模擬構造方法

聲明：

用途：

用於模擬構造方法。

案例：

注意：須要加上註解@PrepareForTest({FileUtils.class})，不然模擬方法不生效。

5. 參數匹配器

在執行單元測試時，有時候並不關心傳入的參數的值，可使用參數匹配器。

5.1. 參數匹配器(any)

Mockito提供Mockito.anyInt()、Mockito.anyString、Mockito.any(Class clazz)等來表示任意值。

5.2. 參數匹配器(eq)

當咱們使用參數匹配器時，全部參數都應使用匹配器。若是要爲某一參數指定特定值時，就須要使用Mockito.eq()方法。

5.3. 附加匹配器

Mockito的AdditionalMatchers類提供了一些不多使用的參數匹配器，咱們能夠進行參數大於(gt)、小於(lt)、大於等於(geq)、小於等於(leq)等比較操做，也能夠進行參數與(and)、或(or)、非(not)等邏輯計算等。

6. verify語句

驗證是確認在模擬過程當中，被測試方法是否已按預期方式與其任何依賴方法進行了交互。

格式：

Mockito.verify(mockObject[,times(int)]).someMethod(somgArgs);

用途：

用於模擬對象方法，直接返回指望的值、異常、應答，或調用真實的方法，無需執行原始方法。

案例：

6.1. 驗證調用方法

6.2. 驗證調用次數

除times外，Mockito還支持atLeastOnce、atLeast、only、atMostOnce、atMost等次數驗證器。

6.3. 驗證調用順序

6.4. 驗證調用參數

6.5. 確保驗證完畢

Mockito提供Mockito.verifyNoMoreInteractions方法，在全部驗證方法以後可使用此方法，以確保全部調用都獲得驗證。若是模擬對象上存在任何未驗證的調用，將會拋出NoInteractionsWanted異常。

備註：Mockito.verifyZeroInteractions方法與Mockito.verifyNoMoreInteractions方法相同，可是目前已經被廢棄。

6.6. 驗證靜態方法

Mockito沒有靜態方法的驗證方法，可是PowerMock提供這方面的支持。

7. 私有屬性

7.1. ReflectionTestUtils.setField方法

在用原生JUnit進行單元測試時，咱們通常採用ReflectionTestUtils.setField方法設置私有屬性值。

注意：在測試類中，UserService實例是經過@Autowired註解加載的，若是該實例已經被動態代理，ReflectionTestUtils.setField方法設置的是代理實例，從而致使設置不生效。

7.2. Whitebox.setInternalState方法

如今使用PowerMock進行單元測試時，能夠採用Whitebox.setInternalState方法設置私有屬性值。

注意：須要加上註解@RunWith(PowerMockRunner.class)。

8. 私有方法

8.1. 模擬私有方法

8.1.1. 經過when實現

8.1.2. 經過stub實現

經過模擬方法stub(存根)，也能夠實現模擬私有方法。可是，只能模擬整個方法的返回值，而不能模擬指定參數的返回值。

8.2. 測試私有方法

8.3. 驗證私有方法

這裏，也能夠用Method那套方法進行模擬和驗證方法。

9. 主要註解

PowerMock爲了更好地支持SpringMVC/SpringBoot項目，提供了一系列的註解，大大地簡化了測試代碼。

9.1. @RunWith註解

@RunWith(PowerMockRunner.class)

指定JUnit 使用 PowerMock 框架中的單元測試運行器。

9.2. @PrepareForTest註解

@PrepareForTest({ TargetClass.class })

當須要模擬final類、final方法或靜態方法時，須要添加@PrepareForTest註解，並指定方法所在的類。若是須要指定多個類，在{}中添加多個類並用逗號隔開便可。

9.3. @Mock註解

@Mock註解建立了一個所有Mock的實例，全部屬性和方法全被置空（0或者null）。

9.4. @Spy註解

@Spy註解建立了一個沒有Mock的實例，全部成員方法都會按照原方法的邏輯執行，直到被Mock返回某個具體的值爲止。

注意：@Spy註解的變量須要被初始化，不然執行時會拋出異常。

9.5. @InjectMocks註解

@InjectMocks註解建立一個實例，這個實例能夠調用真實代碼的方法，其他用@Mock或@Spy註解建立的實例將被注入到用該實例中。

9.6. @Captor註解

@Captor註解在字段級別建立參數捕獲器。可是，在測試方法啓動前，必須調用MockitoAnnotations.openMocks(this)進行初始化。

9.7. @PowerMockIgnore註解

爲了解決使用PowerMock後，提示ClassLoader錯誤。

10. 相關觀點

10.1. 《Java開發手冊》規範

【強制】好的單元測試必須遵照AIR原則。說明：單元測試在線上運行時，感受像空氣（AIR）同樣感受不到，但在測試質量的保障上，倒是很是關鍵的。好的單元測試宏觀上來講，具備自動化、獨立性、可重複執行的特色。

A：Automatic（自動化）

I：Independent（獨立性）

R：Repeatable（可重複）

【強制】單元測試應該是全自動執行的，而且非交互式的。測試用例一般是被按期執行的，執行過程必須徹底自動化纔有意義。輸出結果須要人工檢查的測試不是一個好的單元測試。單元測試中不許使用System.out來進行人肉驗證，必須使用assert來驗證。

【強制】單元測試是能夠重複執行的，不能受到外界環境的影響。

說明：單元測試一般會被放到持續集成中，每次有代碼check in時單元測試都會被執行。若是單測對外部環境（網絡、服務、中間件等）有依賴，容易致使持續集成機制的不可用。

正例：爲了避免受外界環境影響，要求設計代碼時就把SUT的依賴改爲注入，在測試時用spring 這樣的DI框架注入一個本地（內存）實現或者Mock實現。

【推薦】編寫單元測試代碼遵照BCDE原則，以保證被測試模塊的交付質量。

B：Border，邊界值測試，包括循環邊界、特殊取值、特殊時間點、數據順序等。

C：Correct，正確的輸入，並獲得預期的結果。

D：Design，與設計文檔相結合，來編寫單元測試。

E：Error，強制錯誤信息輸入（如：非法數據、異常流程、業務容許外等），並獲得預期的結果。

10.2. 爲何要使用Mock？

根據網絡相關資料，總結觀點以下：

Mock能夠用來解除外部服務依賴，從而保證了測試用例的獨立性。

如今的互聯網軟件系統，一般採用了分佈式部署的微服務，爲了單元測試某一服務而準備其它服務，存在極大的依耐性和不可行性。

Mock能夠減小全鏈路測試數據準備，從而提升了編寫測試用例的速度。

傳統的集成測試，須要準備全鏈路的測試數據，可能某些環節並非你所熟悉的。最後，耗費了大量的時間和經歷，並不必定獲得你想要的結果。如今的單元測試，只須要模擬上游的輸入數據，並驗證給下游的輸出數據，編寫測試用例並進行測試的速度能夠提升不少倍。

Mock能夠模擬一些非正常的流程，從而保證了測試用例的代碼覆蓋率。

根據單元測試的BCDE原則，須要進行邊界值測試（Border）和強制錯誤信息輸入（Error），這樣有助於覆蓋整個代碼邏輯。在實際系統中，很難去構造這些邊界值，也能難去觸發這些錯誤信息。而Mock從根本上解決了這個問題：想要什麼樣的邊界值，只須要進行Mock；想要什麼樣的錯誤信息，也只須要進行Mock。

Mock能夠不用加載項目環境配置，從而保證了測試用例的執行速度。

在進行集成測試時，咱們須要加載項目的全部環境配置，啓動項目依賴的全部服務接口。每每執行一個測試用例，須要幾分鐘乃至幾十分鐘。採用Mock實現的測試用例，不用加載項目環境配置，也不依賴其它服務接口，執行速度每每在幾秒以內，大大地提升了單元測試的執行速度。

10.3. 單元測試與集成測試的區別

在實際工做中，很多同窗用集成測試代替了單元測試，或者認爲集成測試就是單元測試。這裏，總結爲了單元測試與集成測試的區別：

測試對象不一樣

單元測試對象是實現了具體功能的程序單元，集成測試對象是概要設計規劃中的模塊及模塊間的組合。

測試方法不一樣

單元測試中的主要方法是基於代碼的白盒測試，集成測試中主要使用基於功能的黑盒測試。

測試時間不一樣

集成測試要晚於單元測試。

測試內容不一樣

單元測試主要是模塊內程序的邏輯、功能、參數傳遞、變量引用、出錯處理及需求和設計中具體要求方面的測試；而集成測試主要驗證各個接口、接口之間的數據傳遞關係，及模塊組合後可否達到預期效果。

感謝你們的認同與支持，小編會持續轉發《樂字節》優質文章