spring中如何使用Mockito解決Bean依賴樹問題

這篇文章主要介紹了spring中如何使用Mockito解決Bean依賴樹問題，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

前提

基本概念 Junit初始化及存在的問題

spring應用在unit test時，test是獨立運行的，所以需要自行 init ApplicationContext，啟動 Ioc容器。

Junit要求：Test類中涉及的所有Spring bean 注入成功才能完成applicationContext初始化，并啟動IOC容器，否則無法執行unit test。

ApplicationContext初始化的兩種方式 手動注入（使用 @Bean或者 @Component 注入所需的類）編寫@Configuration 類（使用@ComponentScan 指定掃描beans） 兩種初始化方式存在的問題

方式一：

所需的beans中，一個bean少注入了就會導致無法初始化上下文需要注入的bean太多時，需要花費大量的時間和精力，排查缺漏難度大

方式二：

顆粒度難以把控，隨著項目規模變大之后，可能導致bean導入過多，單元測試跑很久才能通過當項目規模大了之后，bean之間的依賴往往是復雜的，掃描bean的方式可能出現一些不屬于自己模塊的未知問題或者某些中間件在unitTest環境無法正常啟動，導致無法初始化上下文 什么是依賴樹？

在開發應用時，往往會出現如上圖的 樹型依賴 ，比如 serviceA 調用 serviceB，serviceB 又調用 serviceC 。

然而這只是一個簡單的例子。真正的開發中，往往一個 service 會依賴多個 service ，以及多個 dao ，以此來實現業務邏輯。

而根據Junit要求，我們必須將樹的路徑經過的所有節點(bean)都注入才能完成spring上下文初始化。這時如果bean之間的依賴耦合過大時，就無法跳脫出兩種初始化方式帶來的問題。

什么是Mockito？

在測試過程中，對于某些不容易構造（如 HttpServletRequest 必須在Servlet 容器中才能構造出來）或者不容易獲取比較復雜的對象（如 JDBC 中的ResultSet 對象），用一個虛擬對象（Mock 對象）來創建以便測試的測試方法。

Mock 最大的功能是幫你把單元測試的耦合分解開，如果你的代碼對另一個類或者接口有依賴，它能夠幫你模擬這些依賴，并幫你驗證所調用的依賴的行為。

簡單來說：就是虛擬一個mock對象，這個對象在單元測試時會“貍貓換太子”，將原有bean進行替換，“騙過”spring初始化，成功啟動ioc容器，以此規避常規初始化方式帶來的種種問題。

開發場景

結合本人在工作中遇見的問題，當時我所寫的模塊進行unitTest時，就出現了依賴樹過于龐大的問題。

首先，我采用了常規的手動注入（方式一），導致注入了很久都沒注入完，無法執行測試。后來覺得這方法在這種情況不可行。然后，我采用了編寫@Configuration 類（方式二），同樣也存在一些問題。一些不屬于我負責模塊的bean也被注入，其中某些涉及TaskSchedule的bean無法被正確注入，導致無法執行測試。此時一個個bean探索，解決問題顯然不現實。最后，我采用Junit+Mockito結合的方式進行單元測試。按照依賴樹大小進行區分。 依賴樹小的直接使用常規的手動注入（方式一），省事，同時保證大部分邏輯按照代碼正常運行依賴樹大的使用Mockito，避免前文提到的兩種初始化方式導致的問題

使用 1 導入maven依賴

首先導入mockito maven依賴,版本請根據自己的spring版本選擇，否則會出現不兼容的情況。

<dependency>      <groupId>org.springframework.boot</groupId>      <artifactId>spring-boot-starter-test</artifactId>      <scope>test</scope>      <exclusions>        <exclusion>          <groupId>org.junit.vintage</groupId>          <artifactId>junit-vintage-engine</artifactId>        </exclusion>      </exclusions>    </dependency>    <dependency>      <groupId>junit</groupId>      <artifactId>junit</artifactId>      <version>4.12</version>      <scope>test</scope>    </dependency>

注意：

此處導入了spring-boot-starter-test是因為這個依賴已經包含了mockito相關的jar包

spring-boot-starter-test可以使用 @MockBean 注解（mockito-core、mockito-all貌似不能）

@Mock和@MockBean的區別:

@Mock

@MockBean mock bean替換時機 spring上下文初始化 完成之后 spring上下文初始化 執行期間 能否“騙”過spring初始化否是 能否解決依賴樹否是 在沒注入所有所需的bean，無法完成spring上下文初始化時，@Mock無法正常工作 @MockBean在初始化時就進行替換，spring上下文初始化時檢測的bean為替換后的mock bean，而mock bean本身是無依賴任何其他bean的，自然能夠“騙”過spring上下文初始化階段，成功啟動IOC容器 2 分析bean之間的依賴

使用一個簡單的Demo進行開發場景的模擬，采用Junit+Mockito結合的方式進行單元測試，根據依賴樹大小區分出是否需要mock

如圖，此處編寫了一個ControllerA，ControllerA中依賴了2個bean：ServiceA，DaoA

分析過程： 關于 DaoA ：由于Dao往往不會依賴其他的bean，所以此處可以使用常規的手動注入（方式一）即可。方便快捷關于 ServiceA ：由于serviceA依賴了serviceB（->DaoB）、serviceC(->DaoC),像這樣的嵌套依賴的bean就可以使用Mockito，來解決依賴樹問題 3 編寫Test類

daoA使用@Bean注解注入即可

@Bean    public DaoA daoA(){      return new DaoAImpl();    }

1.serviceA首先使用@MockBean注解，將serviceA模擬為Mock Bean，它將在spring上下文初始化時就替換掉原有Bean

@MockBean  private ServiceA serviceA;

2.在test類執行前（@Before），使用Mockito API設置調用某個方法的返回值(你預期得到的返回結果)，在Test類中調用這個方法時就會返回所指定的值

@Before  public void init(){    MockitoAnnotations.initMocks(this);//只使用 @MockBean 時可省略這句    when(controllerA.serviceA_method()).thenReturn("666");  }

3.使用 @InjectMocks 通知依賴了serviceA的controllerA，在spring啟動時，對controllerA這個bean進行相應的后置處理

@Autowired  @InjectMocks  private ControllerA controller;

4.單元測試時，就不會使用原有Bean的方法，而是使用Mock Bean及其已經指定了返回值的方法

@Test  public void testDeepMock() {    String s = controllerA.serviceA_method();    System.out.println(s);  }

5.unitTest結果

感謝你能夠認真閱讀完這篇文章，希望小編分享的“spring中如何使用Mockito解決Bean依賴樹問題”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!