本文介绍如何在 JUnit 5 + Mockito 中结合 @ParameterizedTest 灵活地为不同参数组合动态模拟不同的仓库方法调用，避免硬编码 stub，提升测试可维护性与表达力。
本文介绍如何在 junit 5 + mockito 中结合 `@parameterizedtest` 灵活地为不同参数组合动态模拟不同的仓库方法调用，避免硬编码 stub，提升测试可维护性与表达力。
在使用 Mockito 进行单元测试时，若需对多个相似但行为略有差异的场景（如不同查询条件触发不同仓库方法）进行参数化验证，直接在 @ArgumentsProvider 中传递已执行的方法调用（如 myRepository.findComponentByKey_1(...)）是无效的——因为此时方法已被真实调用，而非被“延迟描述”用于后续 when(...).thenReturn(...) 的 stub 操作。
正确的做法是：将待模拟的方法调用抽象为可延迟执行的函数式接口实例（如 Supplier<list>></list>），使其仅在 when() 中被“引用”，而非提前执行。这样，每个参数化用例就能独立绑定其专属的 stub 行为。
以下是推荐实现方式（使用 @MethodSource 替代自定义 ArgumentsProvider，更简洁、类型安全）：
@ExtendWith(MockitoExtension.class)
public class MyServiceTest {
@Mock
private MyRepository myRepository; // 注意：移除 static 修饰符，@Mock 不支持静态字段
private MyService myService;
@BeforeEach
void setUp() {
myService = new MyService(myRepository);
}
@ParameterizedTest
@MethodSource("args")
void findAllTest(Map<String, String> allParameters, Supplier<List<Element>> methodCall) {
Element element = Element.builder().identification("id").build();
// ✅ 正确：使用 Supplier#get() 获取待 stub 的方法调用表达式
when(methodCall.get()).thenReturn(List.of(element));
var expectedResponse = myService.execute(allParameters);
// ✅ 断言逻辑（根据实际业务补充）
assertNotNull(expectedResponse);
// assert...
}
private static Stream<Arguments> args() {
// ? 每个 Supplier 封装一个待 stub 的具体方法调用（不执行！）
Supplier<List<Element>> findByKey1 = () -> myRepository.findComponentByKey_1("value_1");
Supplier<List<Element>> findByKey2 = () -> myRepository.findComponentByKey_2("value_2");
return Stream.of(
Arguments.of(Map.of("key_1", "value_1"), findByKey1),
Arguments.of(Map.of("key_2", "value_2"), findByKey2)
);
}
}⚠️ 关键注意事项：
-
@Mock字段不能是static，否则 Mockito 扩展无法注入，会导致NullPointerException；务必改为实例字段。 -
Supplier<t></t>是理想选择，因其语义清晰：表示“一个可重复获取 T 的操作”，完美契合when(...)对方法引用的延迟求值需求。 -
@MethodSource必须是static方法，因此myRepository需在args()中通过其他方式提供（例如：在args()内部mock(MyRepository.class)，或改用@TestInstance(TestInstance.Lifecycle.PER_CLASS)配合@BeforeAll初始化 mock）。若需复用同一 mock 实例，推荐后者或提取为常量。 - 切勿在
ArgumentsProvider或@MethodSource中直接调用真实方法（如myRepository.findXxx()），否则会触发真实逻辑或 NPE —— 只能封装为 lambda 或方法引用。
✅ 总结：参数化 stub 的本质是「参数化行为契约」，而非「参数化执行结果」。通过 Supplier 将 stub 目标解耦为可配置的函数式描述，配合 @ParameterizedTest，即可实现高内聚、低耦合、易演进的测试设计。
