本文详解 Mockito 中 mock 同一方法但不同参数时的常见错误及解决方案，重点说明为何直接使用字面量参数会触发“Unused stubbing”警告，以及如何通过 eq() 等参数匹配器实现精准、隔离的模拟行为。
本文详解 mockito 中 mock 同一方法但不同参数时的常见错误及解决方案，重点说明为何直接使用字面量参数会触发“unused stubbing”警告，以及如何通过 `eq()` 等参数匹配器实现精准、隔离的模拟行为。
在使用 Mockito 编写单元测试时，一个常见误区是：在多个独立测试方法中，对同一 mock 对象的方法进行不同参数的 stubbing（如 when(service.getValue("param1")).thenReturn(...)），却未在对应测试中实际调用该方法。这正是你遇到 [MockitoHint] Unused stubbing 警告的根本原因。
Mockito 的 stubbing（即 when(...).thenReturn(...)）本身不会自动绑定到后续调用；它只是声明“当满足某条件时返回什么”。而 Mockito 在每个测试方法执行完毕后，会检查所有已声明的 stubbing 是否被真实触发过。若某 stubbing 从未被调用（例如你在 firstTest() 中 stubbed "parameter1"，但测试逻辑中实际调用的是 "parameter2" 或根本没调用 getValue()），Mockito 就会发出警告——这不是语法错误，而是设计上的“未使用存根”提示，用于帮助开发者发现潜在的测试冗余或逻辑遗漏。
⚠️ 注意：Mockito.anyString() 不触发该警告，并非因为它“更安全”，而是因为它是一个宽泛匹配器，能匹配任意字符串参数，因此只要测试中调用了 getValue(...)（无论传什么字符串），该 stubbing 就会被视为“已使用”。但这牺牲了测试的精确性与可维护性——你无法区分 "parameter1" 和 "parameter2" 的行为差异。
✅ 正确做法是：显式使用 ArgumentMatchers.eq() 配合具体参数值，确保 stubbing 与实际调用严格对应。eq("parameter1") 明确表示“仅当参数等于 "parameter1" 时才生效”，既保持语义清晰，又避免误匹配。
以下是规范写法示例：
import static org.mockito.ArgumentMatchers.eq;
import static org.mockito.Mockito.when;
@Test
public void firstTest() {
// 精准匹配：仅当 getValue("parameter1") 被调用时返回 1
when(service.getValue(eq("parameter1"))).thenReturn(1);
// 实际触发调用（关键！）
int result = testingService.processValue("parameter1");
assertEquals(1, result);
}
@Test
public void secondTest() {
// 独立 stubbing：仅当 getValue("parameter2") 被调用时返回 2
when(service.getValue(eq("parameter2"))).thenReturn(2);
// 实际触发调用
int result = testingService.processValue("parameter2");
assertEquals(2, result);
}
? 关键要点总结：
- 每个测试方法必须实际调用其 stubbed 的方法，否则 Mockito 认为该 stubbing 是冗余的；
- 优先使用 eq() 而非字面量字符串：eq("x") 是 Mockito 推荐的显式参数匹配方式，语义明确且与 anyString() 有本质区别；
- 避免跨测试复用 stubbing：每个 @Test 方法应独立 setup 所需的 mock 行为，保证测试隔离性；
- 检查 @Mock 和 @InjectMocks 的初始化时机：确保 service 确实是被 @Mock 注入的 mock 实例，而非真实对象（可通过 verify(service).getValue(...) 辅助验证）；
- 若需更复杂的参数校验（如自定义对象匹配），可结合 argThat() 或自定义 ArgumentMatcher。
遵循以上原则，即可在多测试场景下安全、精准地控制 mock 行为，让测试既健壮又可读。
