Java测试中怎么使用Mockito模拟依赖对象

在编写Java单元测试时，如果被测类依赖了数据库、第三方远程接口或未完成的外部组件，测试执行就会变得缓慢且脆弱。Mockito解决这个问题的核心路径，是用一个虚构的“替换对象”（Mock）代替真实的外部依赖，由测试代码主动定义该对象在特定调用下的返回值或异常行为，从而将被测逻辑与外部环境彻底解耦，在本地内存中完成快速验证。

为什么需要模拟依赖对象

单元测试的立足点在于验证“当前类”本身的业务逻辑是否准确。如果一个 OrderService（订单服务）内部调用了 PaymentClient（支付网关）和 OrderRepository（数据库访问层），在没有Mock工具的情况下，测试用例必须启动真实数据库，甚至需要连接远程沙箱环境。这不仅会导致测试速度变慢，还可能因为网络抖动或测试数据冲突产生误报。

引入Mockito之后，测试只针对 OrderService，所有的外部协作方都被替换为受控的替身对象。测试用例可以精确指定依赖项在接收到特定参数时返回什么数据、抛出何种异常，并在执行完毕后检查依赖项的方法是否被准确调用。

图1：真实依赖与模拟依赖在运行结构上的对照

准备工作：引入依赖

在项目中引入测试框架。现代项目通常结合 JUnit 5 与 Mockito 使用。如果在 Maven 项目中，需要在 pom.xml 的 区域添加如下依赖：

    org.mockito
    mockito-core
    5.11.0
    test


    org.mockito
    mockito-junit-jupiter
    5.11.0
    test

如果使用的是 Gradle，在 build.gradle 中添加：

testImplementation 'org.mockito:mockito-core:5.11.0'
testImplementation 'org.mockito:mockito-junit-jupiter:5.11.0'

模拟依赖对象的四步执行流

在单元测试中使用 Mockito，基本遵循固定的操作流程：初始化环境与创建模拟对象、设定预设行为（Stubbing）、执行目标方法、验证结果与交互行为。这四个环节构成了测试用例的标准骨架。

图2：使用 Mockito 编写测试的标准生命周期

1. 创建与注入模拟对象

创建模拟对象有两种方式：通过代码调用 Mockito.mock(Class)，或者使用注解 @Mock 与 @InjectMocks。在具备一定规模的工程中，使用注解更清晰。

设想一个用户注册场景，UserService 依赖 UserRepository 保存用户，以及 NotificationSender 发送开户邮件：

// 业务类结构
public class UserService {
    private final UserRepository userRepository;
    private final NotificationSender notificationSender;

    public UserService(UserRepository userRepository, NotificationSender notificationSender) {
        this.userRepository = userRepository;
        this.notificationSender = notificationSender;
    }

    public boolean register(String email, String username) {
        if (userRepository.existsByEmail(email)) {
            return false;
        }
        User user = new User(email, username);
        userRepository.save(user);
        notificationSender.sendWelcome(email);
        return true;
    }
}

在测试类中使用注解定义依赖：

@ExtendWith(MockitoExtension.class) // 启用 Mockito 扩展支持
class UserServiceTest {

    @Mock
    private UserRepository userRepository; // 依赖项 A 被模拟

    @Mock
    private NotificationSender notificationSender; // 依赖项 B 被模拟

    @InjectMocks
    private UserService userService; // 将上述 Mock 对象自动注入到被测实例中
}

@Mock 创建了一个虚拟实例，其所有成员方法均未搭载真实逻辑；@InjectMocks 则会自动根据构造器、Setter 或字段反射，将打了 @Mock 标签的实例注入到 UserService 中。

2. 设定模拟行为（Stubbing）

默认情况下，Mock 对象的所有方法都会返回类型的默认值（对象返回 null，数字返回 0，布尔值返回 false）。为了测试特定场景，需要对它的行为进行打桩。

常用的语法是 when(mock.method(args)).thenReturn(value)：

// 设定：当查询 test@example.com 时，返回该邮箱已存在
when(userRepository.existsByEmail("test@example.com")).thenReturn(true);

// 设定：当查询 new@example.com 时，返回该邮箱不存在
when(userRepository.existsByEmail("new@example.com")).thenReturn(false);

如果需要模拟依赖服务抛出异常（例如数据库连接超时），可以使用 thenThrow：

when(userRepository.save(any(User.class)))
    .thenThrow(new DataAccessException("数据库写入失败"));

对于返回值类型为 void 的方法（如 notificationSender.sendWelcome(email)），无法作为 when(...) 的内部参数。此时需要采用反向写法 doThrow 或 doNothing：

// void 方法抛出异常的设定方式
doThrow(new RuntimeException("邮件服务不可用"))
    .when(notificationSender).sendWelcome("fail@example.com");

3. 验证交互行为（Verification）

单元测试不仅关注“返回了什么”，还必须验证“依赖对象是否被合理操作”。例如：当邮箱已存在时，注册流程应该直接退出，绝不应该调用 save 方法或发送邮件。

Mockito 提供了 verify() 函数用于检查调用状态：

// 验证 userRepository.save() 方法被调用了恰好 1 次
verify(userRepository, times(1)).save(any(User.class));

// 验证 notificationSender 的方法从未被调用过
verify(notificationSender, never()).sendWelcome(anyString());

完整测试代码示例

将上述各个环节组合在一起，针对 UserService.register 方法编写两个典型分支用例：注册成功分支与邮箱已存在分支。

import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;

import static org.junit.jupiter.api.Assertions.*;
import static org.mockito.ArgumentMatchers.any;
import static org.mockito.ArgumentMatchers.anyString;
import static org.mockito.Mockito.*;

@ExtendWith(MockitoExtension.class)
class UserServiceTest {

    @Mock
    private UserRepository userRepository;

    @Mock
    private NotificationSender notificationSender;

    @InjectMocks
    private UserService userService;

    @Test
    @DisplayName("新邮箱注册：应保存用户并发送欢迎邮件")
    void testRegisterSuccess() {
        // 1. 打桩：邮箱未被占用
        when(userRepository.existsByEmail("new@example.com")).thenReturn(false);

        // 2. 执行被测方法
        boolean result = userService.register("new@example.com", "Alice");

        // 3. 校验结果与交互
        assertTrue(result);
        verify(userRepository, times(1)).save(any(User.class));
        verify(notificationSender, times(1)).sendWelcome("new@example.com");
    }

    @Test
    @DisplayName("已占用邮箱注册：应直接返回失败，且不触发保存与通知")
    void testRegisterDuplicateEmail() {
        // 1. 打桩：邮箱已被占用
        when(userRepository.existsByEmail("exist@example.com")).thenReturn(true);

        // 2. 执行被测方法
        boolean result = userService.register("exist@example.com", "Bob");

        // 3. 校验结果与交互
        assertFalse(result);
        verify(userRepository, never()).save(any(User.class));
        verify(notificationSender, never()).sendWelcome(anyString());
    }
}

核心机制对比：Mock 与 Spy 的区别

在 Mockito 中，除了 @Mock，另一个常引起混淆的概念是 @Spy。两者在面对没有被打桩的方法时，处理机制截然相反。

图3：Mock 与 Spy 在方法调用策略上的行为差异

这个差异之所以重要，是因为滥用 Spy 往往会导致测试失去隔离意义：

• 全虚拟（Mock）：创建的是空壳。即便被模拟的类内部有读取文件或抛出系统异常的语句，只要没有打桩该方法，它就只会返回默认零值，不会产生任何实际副作用。
• 部分模拟（Spy）：包装的是真实对象实例。当调用一个没有被显式打桩的方法时，底层的真实业务逻辑会被执行。此外，给 Spy 对象打桩时，通常建议使用 doReturn(...).when(spy).method() 语法，避免使用 when(spy.method()) 时意外触发真实方法的执行。

参数匹配器与使用陷阱

在打桩或验证方法时，如果不限制具体的入参值，可以使用参数匹配器（Argument Matchers），例如 any()、anyString()、eq() 等。但在使用过程中必须遵守一条核心语法规则：

// 错误写法：会抛出 InvalidUseOfMatchersException
when(paymentService.pay("ORDER_001", anyDouble())).thenReturn(true);

// 正确写法：具体值需要使用 eq() 包装
when(paymentService.pay(eq("ORDER_001"), anyDouble())).thenReturn(true);

使用要点与注意事项总结

掌握模拟对象的使用方法后，了解合理的测试边界同样重要。以下是日常开发中应该注意的关键原则：

图4：Mockito 使用规范与关键注意事项

• 谨慎模拟静态方法（Static Methods）：自 Mockito 3.4.0 以后，通过 mockStatic() 已经可以支持静态方法模拟。但静态模拟必须写在 try-with-resources 作用域中，或者在用例结束时显式关闭，否则该 Mock 会污染同一线程上的后续测试用例。
• 保持单测专注于业务：当测试中出现“为了验证一个逻辑需要预先打桩十几个 Mock 对象”的情况时，通常是当前业务类职责过多、发生了代码坏味道的信号，应当优先考虑拆分业务类，而不是编写更复杂的 Mock 逻辑。