本文旨在解決在junit 5中使用@ParameterizedTest與Mockito進行單元測試時，常見的InvalidUseOfMatchersException錯誤。核心問題在于JUnit 4的測試運行器（@RunWith(MockitoJUnitRunner.class)）與JUnit 5的擴展模型不兼容。通過詳細示例，我們將展示如何正確地使用JUnit 5的@ExtendWith(MockitoExtension.class)來集成Mockito，確保參數化測試能夠順利地定義和執行模擬對象的行為，從而編寫出更健壯、更靈活的測試用例。
引言
在現代Java應用開發中，單元測試是保障代碼質量不可或缺的一環。JUnit 5作為當前主流的測試框架，提供了強大的參數化測試功能（@ParameterizedTest），允許開發者使用不同的輸入數據多次運行同一個測試方法，極大地提高了測試的效率和覆蓋率。同時，Mockito作為流行的模擬框架，使得對外部依賴進行模擬變得輕而易舉，從而能夠隔離被測單元，專注于其自身的邏輯。
然而，當嘗試將JUnit 5的參數化測試與Mockito結合使用時，一些開發者可能會遇到org.mockito.exceptions.misusing.InvalidUseOfMatchersException這樣的錯誤。這個錯誤通常發生在嘗試在when().thenReturn()等模擬定義中使用any()等參數匹配器時，表明Mockito的上下文環境不正確。
問題分析：JUnit 4 Runner與JUnit 5 Extension的沖突
InvalidUseOfMatchersException的出現，往往是由于JUnit 4的測試運行器（如@RunWith(MockitoJUnitRunner.class)）被錯誤地應用于JUnit 5的測試類上。JUnit 4使用@RunWith注解來指定測試運行器，而JUnit 5則引入了全新的擴展模型，通過@ExtendWith注解來注冊擴展。
當你在一個使用了@ParameterizedTest（JUnit 5特性）的測試類中，同時使用@RunWith(MockitoJUnitRunner.class)時，就會發生沖突。MockitoJUnitRunner是為JUnit 4設計的，它無法正確地初始化Mockito的上下文以支持JUnit 5的生命周期和參數化測試機制。因此，當Mockito嘗試解析any()等參數匹配器時，由于其內部狀態未被正確管理，便會拋出InvalidUseOfMatchersException。
錯誤的示例（導致InvalidUseOfMatchersException）：
import org.junit.jupiter.params.ParameterizedTest; import org.junit.jupiter.params.provider.EnumSource; import org.junit.runner.RunWith; // JUnit 4 Runner import org.mockito.Mocked; // Assuming this is @Mock, typo in original import org.mockito.InjectMocks; import org.mockito.junit.MockitoJUnitRunner; // JUnit 4 Runner import static org.mockito.Mockito.*; import static org.junit.jupiter.api.Assertions.assertEquals; // 假設存在以下輔助類 enum CodeEnum { S1("S1"), S2("S2"); private final String code; CodeEnum(String code) { this.code = code; } public String getCode() { return code; } } class Output { private CodeEnum code; public Output(CodeEnum code) { this.code = code; } public static Output.Builder builder() { return new Output.Builder(); } public CodeEnum getCode() { return code; } static class Builder { private CodeEnum code; public Builder code(CodeEnum code) { this.code = code; return this; } public Output build() { return new Output(code); } } } interface MockedObject { Output method(MockedInput input); } class Foo { private MockedObject mockedObject; public Foo(MockedObject mockedObject) { this.mockedObject = mockedObject; } // 假設 Foo.method() 內部會調用 mockedObject.method() 并傳入某個 MockedInput public Output method() { // 實際實現中，這里會根據業務邏輯生成或獲取 MockedInput // 為簡化示例，我們假設它調用一個默認的或者在測試中被捕獲的輸入 return mockedObject.method(new MockedInput("default_input_for_foo")); } } class MockedInput { private String value; public MockedInput(String value) { this.value = value; } // 需要重寫 equals 和 hashCode 方法，以便 Mockito 正確匹配 @Override public boolean equals(Object o) { if (this == o) return true; if (o == null || getClass() != o.getClass()) return false; MockedInput that = (MockedInput) o; return value != null ? value.equals(that.value) : that.value == null; } @Override public int hashCode() { return value != null ? value.hashCode() : 0; } } // @RunWith(MockitoJUnitRunner.class) // 這是導致問題的原因！ class FooTestIncorrect { @Mock // 注意：原始問題中的 @Mocked 可能是筆誤，通常是 @Mock MockedObject mockedObject; @InjectMocks Foo underTest; @ParameterizedTest @EnumSource(CodeEnum.class) public void test_ParametrizedTest_with_any(CodeEnum codeEnum) { Output expectedReturn = Output.builder().code(codeEnum).build(); // Given // 這里的 any() 在錯誤的 Runner 下可能導致問題 when(mockedObject.method(any())) .thenReturn(expectedReturn); // when val result = underTest.method(); // then assertEquals(codeEnum, result.getCode()); } }
解決方案：使用MockitoExtension
解決這個問題的關鍵在于，對于JUnit 5測試，我們應該使用@ExtendWith(MockitoExtension.class)來替代JUnit 4的@RunWith(MockitoJUnitRunner.class)。MockitoExtension是Mockito為JUnit 5提供的擴展，它能夠正確地初始化和管理Mockito的生命周期，從而與JUnit 5的特性（包括參數化測試）無縫集成。
正確的實現方式：
import org.junit.jupiter.api.extension.ExtendWith; // JUnit 5 Extension import org.junit.jupiter.params.ParameterizedTest; import org.junit.jupiter.params.provider.Arguments; import org.junit.jupiter.params.provider.MethodSource; import org.mockito.Mock; // 正確的注解是 @Mock import org.mockito.InjectMocks; import org.mockito.junit.jupiter.MockitoExtension; // JUnit 5 Mockito Extension import java.util.stream.Stream; import static org.junit.jupiter.api.Assertions.assertEquals; import static org.mockito.Mockito.when; // 輔助類定義同上，此處省略重復代碼 @ExtendWith(MockitoExtension.class) // 正確的JUnit 5 Mockito集成方式 public class FooTest { @Mock MockedObject mockedObject; @InjectMocks Foo underTest; /** * 數據提供者方法，為參數化測試提供輸入和預期輸出。 * 每個 Arguments.of() 包含： * 1. 模擬對象方法所需的輸入 (MockedInput) * 2. 模擬對象方法應返回的預期輸出 (Output) */ private static Stream<Arguments> dataProvider() { // 假設 mockedInput1 和 mockedInput2 是 MockedInput 的實例 MockedInput mockedInput1 = new MockedInput("input_val_S1"); MockedInput mockedInput2 = new MockedInput("input_val_S2"); return Stream.of( Arguments.of(mockedInput1, Output.builder().code(CodeEnum.S1).build()), Arguments.of(mockedInput2, Output.builder().code(CodeEnum.S2).build()) ); } @ParameterizedTest @MethodSource("dataProvider") public void test_ParametrizedTest_with_Mockito(MockedInput inputForMock, Output expectedReturnFromMock) { // Given // 使用參數化測試提供的 inputForMock 來定義模擬對象的行為 when(mockedObject.method(inputForMock)) .thenReturn(expectedReturnFromMock); // When // 調用被測對象的方法。假設 Foo.method() 內部會以某種方式觸發 mockedObject.method(inputForMock) // 例如，Foo 內部可能根據某種邏輯生成或獲取到 inputForMock 并傳遞給 mockedObject val result = underTest.method(); // Then // 驗證被測方法的返回值是否符合預期，預期值來自參數化測試提供的 expectedReturnFromMock assertEquals(expectedReturnFromMock.getCode(), result.getCode()); } }
在上述修正后的代碼中：
- 我們移除了@RunWith(MockitoJUnitRunner.class)。
- 我們添加了@ExtendWith(MockitoExtension.class)，這是JUnit 5與Mockito集成的標準方式。
- @ParameterizedTest和@MethodSource用于提供測試數據。dataProvider()方法返回一個Stream
，其中每個Arguments實例包含一對值：一個MockedInput用于設置模擬行為的輸入，以及一個Output作為模擬方法的返回值。 - 在test_ParametrizedTest_with_Mockito方法中，我們直接使用參數inputForMock來定義mockedObject.method()的模擬行為，并使用expectedReturnFromMock作為其返回值。這使得我們可以針對不同的輸入，靈活地定義模擬對象的響應。
- 斷言部分也更新為使用expectedReturnFromMock.getCode()來與實際結果進行比較，確保邏輯的正確性。
關鍵點與最佳實踐
- JUnit 5與Mockito的集成： 始終使用@ExtendWith(MockitoExtension.class)來在JUnit 5測試類中啟用Mockito的注解（如@Mock, @InjectMocks）和功能。這是JUnit 5生態系統中的標準做法，與JUnit 4的@RunWith有本質區別。
- 參數化測試的數據源：
- @EnumSource: 適用于測試數據來源于枚舉類型的情況。
- @MethodSource: 提供了更大的靈活性，可以從靜態方法中提供任意類型的Stream
作為測試數據，非常適合需要提供復雜對象作為參數，或者需要同時提供模擬輸入和預期輸出的場景。
- 模擬對象行為的定義： 在參數化測試中，可以通過測試方法的參數直接獲取用于定義模擬行為的數據。這使得每個參數化測試迭代都可以擁有獨立的模擬配置，從而實現更精細的測試覆蓋。
- equals()和hashCode()的重要性： 當使用對象作為Mockito的參數匹配器（例如when(mockedObject.method(someObject))）時，如果someObject是一個自定義對象，確保該對象正確地重寫了equals()和hashCode()方法。Mockito在匹配參數時會依賴這些方法來判斷對象是否相等。
總結
通過將JUnit 4的@RunWith(MockitoJUnitRunner.class)替換為JUnit 5的@ExtendWith(MockitoExtension.class)，我們可以有效地解決在JUnit 5參數化測試中遇到的InvalidUseOfMatchersException問題。這種正確的集成方式不僅能讓@ParameterizedTest與Mockito協同工作，還能幫助開發者編寫出更清晰、更靈活、更易于維護的單元測試，從而提升整體代碼質量和開發效率。理解JUnit 5的擴展模型與JUnit 4運行器之間的差異，是掌握現代Java單元測試框架的關鍵一步。
