Mockito中eq() API的作用与适用场景（Kotlin环境）

为什么你的测试加不加eq()都能过？ #

在Kotlin里，像true这种基本类型或值类型，直接传给verify的方法参数时，Mockito会自动用equals()做匹配，和eq(true)的效果完全一致。这就是两种写法都能通过测试的核心原因——本质都是验证onChanged被调用时传入的参数等于true。

eq()和直接传值的核心区别 #

• 匹配器上下文的强制要求：只要在同一个verify或when调用里用了任意一个参数匹配器（比如any()、isNull()、argThat()），所有参数都必须用匹配器包裹，不能混合直接传值。这时候eq()就用来明确指定“我要匹配这个具体值”。
  举个错误的例子：

  // 报错：混合了匹配器和直接传值
  verify(userObserver).updateUser(anyString(), 25)
  

  改成正确写法就需要用eq()：

  // 正确：所有参数都用匹配器
  verify(userObserver).updateUser(anyString(), eq(25))
  

• 语义清晰度：对于一些复杂场景，eq()能更明确地表达“我在做值匹配”的意图，让其他看代码的人一眼就能理解你的测试逻辑，比直接传值的可读性更强。
• 特殊场景适配：虽然Kotlin的数据类默认实现了equals()，但如果是自定义类且重写了equals()，eq()会基于这个方法做匹配，和直接传值效果一致，但语义上更强调匹配逻辑。

什么时候该用eq()？ #

• 当同一个方法调用的验证/存根中已经用了其他参数匹配器，必须用eq()包裹具体值参数，避免Mockito抛出参数匹配器混用的异常。
• 当你想让测试代码的意图更清晰，明确告诉读者“这里是在验证参数的具体值”，尤其是在复杂测试用例里，eq()能提升代码的可读性和维护性。
• 处理非基本类型对象时，用eq()可以明确依赖对象的equals()方法进行匹配，让逻辑更直观。

内容的提问来源于stack exchange，提问作者soiXam