spring中使用Mockito解決Bean依賴樹問題方法
前提
本文不是針對Mockito的入門教學 ，主要敘述如何簡單的使用Mockito解決Bean依賴樹問題，對於Mockito的學習請找其他的文章或者查閱官方文件
基本概念 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的區別:
使用一個簡單的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結果
以上就是本次介紹的全部相關知識點，感謝大家的學習和對我們的支援。