本文旨在解決使用Mockito spy時，被樁（stub）方法未按預期執(zhí)行的問題。核心原因在於生產代碼直接實例化依賴對象，而非使用測試中創(chuàng)建的間諜對象。文章將詳細闡述這一常見誤區(qū)，並提供通過依賴注入（Dependency Injection）進行解耦的解決方案，從而有效提升代碼的可測試性與模塊化程度。

問題剖析：Mockito Spy的常見誤區(qū)

在單元測試中，Mockito 的spy 功能允許我們對一個真實對象進行部分模擬，即可以調用真實對象的方法，也可以對特定方法進行樁（stub）或驗證（verify）。然而，一個常見的誤解是，當生產代碼（即被測試的代碼）內部直接創(chuàng)建了它所依賴的對象實例時，測試中創(chuàng)建的spy 對象將無法生效。

考慮以下生產代碼片段，其中MyService 類直接創(chuàng)建了GetOptionBidPrice 的實例：

 // 生產代碼public class MyService {
    public double calculateBidPrice() {
        // 問題所在：MyService 內部直接實例化GetOptionBidPrice
        GetOptionBidPrice getOptionBidPrice = new GetOptionBidPrice(/* 構造參數*/);
        double bidPrice = getOptionBidPrice.getBidPrice();
        return bidPrice;
    }
}

// 被依賴的類public class GetOptionBidPrice {
    // 假設有構造函數和getBidPrice方法public GetOptionBidPrice(/* 構造參數*/) {
        // ... 初始化...
    }

    public double getBidPrice() {
        // 真實業(yè)務邏輯，可能返回0.0或其他默認值return 0.0;
    }
}

在嘗試測試MyService 時，我們可能會這樣編寫測試代碼，試圖樁化getBidPrice 方法：

 // 測試代碼(錯誤示範)
import org.junit.jupiter.api.Test;
import static org.mockito.Mockito.*;

public class MyServiceTest {

    @Test
    void testCalculateBidPriceWithSpy() {
        // 1. 創(chuàng)建MyService 實例MyService myService = new MyService();

        // 2. 創(chuàng)建GetOptionBidPrice 的間諜對象並樁化其方法// 注意：這裡創(chuàng)建的spyGetOptionBidPrice 是一個獨立的實例GetOptionBidPrice spyGetOptionBidPrice = spy(new GetOptionBidPrice(/* 構造參數*/));
        doReturn(100.0).when(spyGetOptionBidPrice).getBidPrice();

        // 3. 調用MyService 的方法double result = myService.calculateBidPrice();

        // 預期結果是100.0，但實際結果會是0.0
        // 因為myService 內部創(chuàng)建了一個全新的GetOptionBidPrice 實例，而不是我們樁化的spyGetOptionBidPrice
        System.out.println("實際結果: " result); // 輸出0.0
        // assertEquals(100.0, result); // 斷言失敗}
}

問題根源：上述測試代碼的問題在於，MyService 內部的calculateBidPrice 方法在執(zhí)行時，會通過new GetOptionBidPrice() 語句重新創(chuàng)建一個全新的GetOptionBidPrice 實例。這個新實例與我們在測試中創(chuàng)建並樁化的spyGetOptionBidPrice 實例是完全不同的兩個對象。因此，MyService 內部調用的getBidPrice() 方法是新實例的真實方法，而不是間諜對像上被樁化的方法，導致樁化操作未能生效。

解決方案：擁抱依賴注入

解決這一問題的核心思想是：將依賴對象的創(chuàng)建和管理從被依賴類中分離出來，讓被依賴類不再直接負責創(chuàng)建其依賴。這種設計模式被稱為依賴注入（Dependency Injection, DI） 。通過依賴注入，我們可以在測試時注入一個spy 或mock 對象，而在生產環(huán)境中註入真實對象。

依賴注入有多種實現方式，最常見的是構造函數注入和方法注入。

1. 構造函數注入

這是最推薦的方式，尤其適用於強制性依賴。被依賴對像在構造時就接收其所有依賴。

改造後的生產代碼：

 // 生產代碼(使用構造函數注入)
public class MyService {
    private final GetOptionBidPrice getOptionBidPrice;

    // 依賴通過構造函數注入public MyService(GetOptionBidPrice getOptionBidPrice) {
        this.getOptionBidPrice = getOptionBidPrice;
    }

    public double calculateBidPrice() {
        // 現在MyService 使用的是注入進來的GetOptionBidPrice 實例return getOptionBidPrice.getBidPrice();
    }
}

改造後的測試代碼：

 // 測試代碼(使用構造函數注入)
import org.junit.jupiter.api.Test;
import static org.mockito.Mockito.*;
import static org.junit.jupiter.api.Assertions.assertEquals;

public class MyServiceTest {

    @Test
    void testCalculateBidPriceWithInjectedSpy() {
        // 1. 創(chuàng)建GetOptionBidPrice 的間諜對象並樁化其方法GetOptionBidPrice spyGetOptionBidPrice = spy(new GetOptionBidPrice(/* 構造參數*/));
        doReturn(100.0).when(spyGetOptionBidPrice).getBidPrice();

        // 2. 將間諜對象注入到MyService 實例中MyService myService = new MyService(spyGetOptionBidPrice);

        // 3. 調用MyService 的方法double result = myService.calculateBidPrice();

        // 現在，MyService 內部調用的是我們注入的間諜對象的getBidPrice() 方法assertEquals(100.0, result);
        verify(spyGetOptionBidPrice).getBidPrice(); // 驗證方法是否被調用}
}

2. 方法注入

如果依賴不是每次操作都必須的，或者需要在特定方法執(zhí)行時才提供，可以使用方法注入。

改造後的生產代碼：

 // 生產代碼(使用方法注入)
public class MyService {
    public double calculateBidPrice(GetOptionBidPrice getOptionBidPrice) {
        // 依賴通過方法參數注入return getOptionBidPrice.getBidPrice();
    }
}

改造後的測試代碼：

 // 測試代碼(使用方法注入)
import org.junit.jupiter.api.Test;
import static org.mockito.Mockito.*;
import static org.junit.jupiter.api.Assertions.assertEquals;

public class MyServiceTest {

    @Test
    void testCalculateBidPriceWithMethodInjectedSpy() {
        // 1. 創(chuàng)建GetOptionBidPrice 的間諜對象並樁化其方法GetOptionBidPrice spyGetOptionBidPrice = spy(new GetOptionBidPrice(/* 構造參數*/));
        doReturn(100.0).when(spyGetOptionBidPrice).getBidPrice();

        // 2. 創(chuàng)建MyService 實例MyService myService = new MyService();

        // 3. 調用MyService 的方法時，將間諜對像作為參數傳入double result = myService.calculateBidPrice(spyGetOptionBidPrice);

        assertEquals(100.0, result);
        verify(spyGetOptionBidPrice).getBidPrice();
    }
}

依賴注入的優(yōu)勢

除了解決spy 不生效的問題，依賴注入還帶來了多方面的好處：

• 提高可測試性：模塊之間的依賴關係清晰，方便在測試中替換為mock 或spy 對象，從而隔離測試範圍，實現真正的單元測試。
• 降低耦合度：對像不再直接負責創(chuàng)建和管理其依賴，而是由外部（如IoC 容器或測試代碼）提供，使得模塊之間的耦合度降低，更易於維護和修改。
• 提升代碼可維護性和擴展性：當依賴發(fā)生變化時，只需修改注入點，而無需修改依賴類內部的創(chuàng)建邏輯。這使得系統(tǒng)更容易適應需求變化。
• 更好的代碼結構：強制開發(fā)者思考模塊間的依賴關係，有助於設計出更清晰、更符合單一職責原則的類。

總結與最佳實踐

當您在使用Mockito 的spy 或mock 功能時發(fā)現樁化或模擬的行為未能按預期執(zhí)行，一個首要的排查方向就是檢查您的生產代碼是否直接實例化了其依賴。如果是，那麼依賴注入就是解決這個問題的關鍵。

關鍵點：

• 避免在被測試類內部直接new 依賴對象。
• 優(yōu)先使用構造函數注入來處理強制性依賴。
• 考慮使用方法注入處理可選或上下文相關的依賴。
• 利用Mockito 的@InjectMocks 和@Mock/@Spy 註解可以簡化測試代碼，Mockito 會嘗試自動注入依賴。

通過採納依賴注入模式，不僅能有效解決Mockito spy 的使用問題，更能從根本上提升代碼的質量、可測試性和可維護性，是現代軟件開發(fā)中不可或缺的設計實踐。

以上是解決Mockito Spy方法未被調用：深度解析與依賴注入實踐的詳細內容。更多資訊請關注PHP中文網其他相關文章！