深入解析 Mockito 核心注解：@Mock 与 @InjectMocks 的实战指南

2026-02-10 00:32:13 0条评论 2次阅读 0人点赞

在编写 Java 单元测试时，你是否曾为如何模拟复杂的依赖关系而感到头疼？作为开发者，我们深知单元测试的重要性，但在面对层层嵌套的依赖时，测试代码往往会变得难以维护。这时，Mockito 这样的模拟框架便成为了我们手中的利器。

在 Mockito 的众多特性中，@Mock 和 @InjectMocks 是两个最基础却也最容易让人混淆的注解。理解它们的本质区别，不仅能让你写出更简洁的测试代码，还能确保你真正在测试“逻辑”而不是“依赖”。在这篇文章中，我们将摒弃枯燥的定义，通过实际的代码场景和深入的分析，一起探索这两个注解背后的工作机制、最佳实践以及那些容易被忽视的细节。

什么是 Mockito？为什么我们需要它？

在深入注解之前，让我们先快速达成共识。Mockito 是一个强大的 Java 测试框架，它的核心思想是“模拟”。在单元测试中，我们的目标是验证某个类（通常称为“被测类”或 System Under Test）的业务逻辑是否正确。然而，现代应用程序通常由多个通过接口相互协作的类组成。例如，一个 Service 类可能依赖于一个 Repository 类来访问数据库，或者依赖于一个 ExternalApiClient 来调用第三方服务。

如果在测试中我们真实地实例化这些依赖，可能会导致以下问题：

环境依赖：数据库必须启动，网络必须连接，这使得测试变慢且不稳定。
副作用：我们不希望仅仅为了测试一个逻辑就真的向数据库写入脏数据。

Mockito 的解决方案是：创建一个“假”的对象，这个对象拥有和真实对象一样的接口，但我们可以完全控制它的行为。这样，我们就可以把被测类隔离出来，专注测试其内部逻辑。

核心概念：@Mock 与 @InjectMocks 的本质区别

如果让我们用一句话来概括它们的关系，那就是：

> @Mock 负责制造“替身”，而 @InjectMocks 负责将“替身”注入到“主角”身上。

为了更直观地理解，让我们想象一个场景：你要拍一场动作戏。

@Mock：就像是剧组的特技演员（替身）。你不需要他真的去演戏，你只需要他在特定的时候做出特定的动作（比如“摔倒”或“被打”），然后返回一个结果。在 Mockito 中，我们通过 when().thenReturn() 来指导这个替身的行为。
@InjectMocks：就像是剧组的主角。这是真正要被测试的对象。他需要一个搭档来完成表演。Mockito 会自动把前面创建的那些“特技演员”（Mock 对象）塞到主角的手中，让他可以开始表演。

让我们通过代码深入理解

为了彻底弄懂这两者的区别，光说不练是不行的。让我们构建一个稍微复杂一点的案例。

#### 场景设定：在线书店系统

假设我们正在开发一个书店系统。我们有以下两个类：

BookRepository（数据仓库）：负责从数据库获取书籍详情。这是我们需要模拟的外部依赖。
BookService（业务服务）：包含业务逻辑，比如根据书名打折。

代码示例 1：定义实体和依赖

// Book.java
public class Book {
    private String title;
    private double price;

    // 构造函数、getter 和 setter
    public Book(String title, double price) {
        this.title = title;
        this.price = price;
    }

    public double getPrice() {
        return price;
    }

    public String getTitle() {
        return title;
    }
}

// BookRepository.java (接口)
public interface BookRepository {
    Book findBookByTitle(String title);
}

// BookService.java (被测类)
public class BookService {
    
    private final BookRepository repository;

    // 通过构造器注入依赖
    public BookService(BookRepository repository) {
        this.repository = repository;
    }

    // 业务逻辑：获取书价，如果书名包含 "Java"，打 8 折
    public double getDiscountedPrice(String title) {
        Book book = repository.findBookByTitle(title);
        if (book == null) {
            throw new RuntimeException("Book not found");
        }
        
        double price = book.getPrice();
        if (title.contains("Java")) {
            return price * 0.8;
        }
        return price;
    }
}

#### 编写测试类：见证奇迹的时刻

现在，让我们编写测试。在这里，我们将看到 INLINECODEcae6c197 和 INLINECODE8094572e 是如何协同工作的。

代码示例 2：基础测试用例

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.Mockito;
import org.mockito.junit.MockitoJUnitRunner;

import static org.junit.Assert.assertEquals;
import static org.mockito.ArgumentMatchers.anyString;
import static org.mockito.Mockito.when;

// 使用 MockitoJUnitRunner 来启用注解初始化
@RunWith(MockitoJUnitRunner.class)
public class BookServiceTest {

    // 1. @Mock: 创建一个 BookRepository 的模拟对象。
    // 我们不需要真实的数据库连接，只需要控制它的返回值。
    @Mock
    private BookRepository repository;

    // 2. @InjectMocks: 创建 BookService 的实例。
    // Mockito 会自动检测到 BookService 的构造函数需要一个 BookRepository，
    // 并将上面那个 @Mock 标注的 repository 注入进去。
    @InjectMocks
    private BookService service;

    @Test
    public void testGetDiscountedPrice_ForJavaBook() {
        // --- 准备阶段 ---
        // 定义当 repository.findBookByTitle 被调用时，返回什么样的模拟数据
        // 这里我们不需要真正的 Book 对象，只需要一个符合预期的假对象
        Book mockBook = new Book("Java Programming", 100.0);
        when(repository.findBookByTitle("Java Programming")).thenReturn(mockBook);

        // --- 执行阶段 ---
        // 调用被测类的方法
        double price = service.getDiscountedPrice("Java Programming");

        // --- 断言阶段 ---
        // 验证结果是否符合预期（100 * 0.8 = 80）
        assertEquals(80.0, price, 0.01);
        
        // 可选：验证 repository 的方法确实被调用了一次
        Mockito.verify(repository).findBookByTitle("Java Programming");
    }

    @Test(expected = RuntimeException.class)
    public void testGetDiscountedPrice_WhenBookNotFound() {
        // 模拟书不存在的情况
        when(repository.findBookByTitle(anyString())).thenReturn(null);

        // 调用方法，预期抛出异常
        service.getDiscountedPrice("NonExistentBook");
    }
}

#### 深入解析：代码背后发生了什么？

让我们停下来分析一下上面的代码，看看这两个注解具体做了什么：

对象的创建：在测试运行前，Mockito 框架扫描 INLINECODEafb8a6b1 注解，并利用字节码生成技术（如 CGLIB 或动态代理）创建了一个 INLINECODE0c24be83 的代理类实例。这个实例并没有真实的数据库逻辑，它只是一个“壳”。

注入逻辑：接着，Mockito 扫描到 INLINECODE4384a055。它尝试实例化 INLINECODE204c19c6。它发现 INLINECODE07810b7d 只有一个构造函数，参数类型是 INLINECODEe893ac77。于是，它看了一眼手里有哪些 Mock 对象，发现刚才创建的 INLINECODE3ad23cd5 正好匹配，就直接把它传给了 INLINECODE525e3c3a 的构造函数。

为什么不用 new？

你可能会问：“我为什么不直接写 BookService service = new BookService(repository);？”

确实，你可以这么做。当依赖很少时，手动构造甚至可能更清晰。但是，想象一下如果你的 INLINECODE57ede163 依赖了 5 个其他的 Service，而这些 Service 又各自依赖了更多的 Repository。手动 INLINECODE55899f1e 出所有的依赖并组装它们会非常痛苦（这就叫“依赖地狱”）。使用 @InjectMocks，框架会自动帮你处理这种复杂的组装过程，无论是通过构造器注入、Setter 注解注入还是字段反射注入。

对比分析表：何时使用哪个？

为了巩固记忆，让我们通过一个详细的对比表来看看它们在不同维度上的差异。

特性

@Mock

@InjectMocks :—

:—

:— 主要目标

创建一个虚假的、可被操纵的对象（替身）。

创建一个真实的对象实例，并将 Mock 对象注入其中（主角）。 对象类型

通常是外部依赖，如 Repository、Client、Util 类。

通常是被测类（System Under Test），即包含我们要测试的业务逻辑的类。 行为控制

需要。通常需要配合 when().thenReturn() 来定义它在特定输入下的行为。

不需要。我们不定义它的行为，我们是调用它的真实方法来测试逻辑。 实例化方式

Mockito 完全接管，创建类的模拟实现。

Mockito 尝试通过构造函数、Setter 或字段反射来实例化真实类。 常用场景

当你需要隔离外部依赖（如数据库、Web 服务）时使用。

当你需要测试某个类如何与其依赖项交互时使用。

进阶实战：模拟 Setter 注入与字段注入

虽然构造函数注入是最佳实践，但在实际项目中，我们经常遇到没有明确构造函数的遗留代码。让我们看看在这种情况下 @InjectMocks 是如何工作的。

代码示例 3：使用字段注入

public class OrderService {
    // 这里没有构造函数，直接依赖注入
    private PaymentService paymentService;

    public boolean processOrder(double amount) {
        // 如果 paymentService 为空，直接抛出异常
        if (paymentService == null) {
            return false;
        }
        return paymentService.pay(amount);
    }
}

// 测试类
@RunWith(MockitoJUnitRunner.class)
public class OrderServiceFieldInjectionTest {

    @Mock
    private PaymentService paymentService; // Mock 对象

    @InjectMocks
    private OrderService orderService; // 这里的 paymentService 会被自动注入

    @Test
    public void testFieldInjection() {
        // 模拟支付服务返回 true
        when(paymentService.pay(100.0)).thenReturn(true);

        // 调用被测方法
        boolean result = orderService.processOrder(100.0);

        // 验证
        assertTrue(result);
    }
}

在这个例子中，INLINECODE41157de8 没有构造函数。Mockito 足够智能，它会尝试通过反射直接访问 INLINECODE9770b9f8 字段，并将 Mock 对象赋值给它。这就是为什么即使我们没有显式地调用 new，对象内部的状态也被正确初始化了。

常见陷阱与解决方案

作为经验丰富的开发者，我们发现很多开发者在使用这两个注解时会遇到一些常见的坑。避开它们可以让你的测试更加健壮。

#### 陷阱 1：滥用 @InjectMocks 导致测试逻辑变味

有时候，我们可能会想测试 INLINECODEa169ca84 和 INLINECODE578c3f33 的交互。如果你把 INLINECODE9f0b12a2 也标记为 INLINECODE2bc6fb40，并将它注入到 ServiceA 中，那你测的是什么？

错误做法：将被测对象的依赖也变成被测对象。这意味着你实际上在测试两个类的逻辑，这不再是“单元”测试，而是“集成”测试。
正确做法：只有最顶层的被测类使用 INLINECODE7f6aff69。它的所有依赖都应该使用 INLINECODEd19a5d6f。

#### 陷阱 2：Mockito 无法注入 Final 或 Static 类

Mockito 的底层机制是通过子类化或动态代理来实现 Mock 的。

Final 类/方法：在 Java 早期版本中，Mockito 无法 Mock final 类。虽然在较新版本（ Mockito 2.x+ 配合 inline mock maker）中已经解决了这个问题，但在某些配置下仍然可能报错。
Static 方法：这是 Mockito 的痛点。如果你依赖一个静态工具类（如 INLINECODE6927e953），INLINECODE3a8e4ac7 是无法生效的。对于这种情况，通常建议重构代码将其包装成实例方法，或者使用专门的工具。

#### 陷阱 3：当有多个构造函数时的注入歧义

如果你的被测类有多个构造函数，Mockito 默认会尝试使用“参数最多”的那个构造函数。这通常是你想要的（依赖注入通常通过大构造函数完成）。但是，如果构造函数逻辑复杂（比如在构造函数里就执行了逻辑），@InjectMocks 可能会导致测试过早失败或行为异常。

建议：保持构造函数简单，只进行赋值操作。

#### 陷阱 4：INLINECODE90761a23 与 INLINECODE8af608a8 的混合使用

你可能会遇到需要部分模拟的情况，即“调用真实方法，但模拟其中某些依赖”。这时你可能会用到 @Spy。

注意：INLINECODEa8d4ad95 可以注入 INLINECODE717528c6 对象，也可以注入 @Spy 对象。但是，如果你把一个 Spy 对象注入进去，Mockito 会尝试先调用 Spy 的无参构造函数（如果有），这可能会导致意想不到的状态初始化。通常情况下，InjectMocks 内部只放 Mock 对象是最稳妥的。

最佳实践与优化建议

为了让你的单元测试更加专业、快速且易于维护，以下是我们总结的几条实战建议：

优先使用构造函数注入：这不仅仅是 Mockito 的建议，更是 Java 开发的最佳实践。它让依赖关系一目了然，并且配合 @InjectMocks 时最不容易出错。

保持测试的独立性：确保每个 INLINECODE307b7f5c 方法都可以独立运行。不要依赖 INLINECODEd83f130f 对象在多个测试方法之间的状态残留，尽量在每个测试方法内部使用 when() 来定义特定的行为。

Mockito 并不是万能的：如果发现你在测试中编写了大量的 when().thenReturn()，这通常意味着被测类做了太多的事情（“上帝对象”的迹象）。这不仅仅是测试的问题，更是代码设计的警告。考虑重构你的类，使其遵循单一职责原则。

验证行为：除了验证结果，不要忘记使用 INLINECODEe539d802 来验证交互。例如，在“删除用户”的测试中，你可能不仅想验证返回值是 INLINECODEa1ee6f66，还想验证 repository.delete() 确实被调用了一次。

使用 ArgumentMatchers 灵活匹配：在编写 INLINECODEb7a4d933 语句时，尽量使用 INLINECODE08d3a835, INLINECODE9fb454bb, INLINECODEbbd51dc2 等匹配器，而不是写死具体的参数值。这样可以让测试用例更能适应未来的需求变更。

性能优化：@Mock 的代价

虽然 Mock 对象比真实对象轻量得多，但如果你的测试套件中有成千上万个测试类，每个类都初始化大量的 Mock 对象，累积起来也会影响构建速度。

优化建议：对于小型、局部的 Mock，使用 Java 代码手动 Mock（使用匿名内部类）有时比框架 Mock 更快，但通常不建议，因为这会增加代码量。更实际的做法是，确保持有 INLINECODE5a672583 字段的类被标记为 INLINECODE0b5f50e9 或者使用了 MockitoAnnotations.openMocks()，以确保 Mock 对象被正确缓存和重用。

总结

回顾我们的探索，INLINECODEdcfb8024 和 INLINECODE07c73eb3 是 Mockito 框架中相辅相成的两大利器。

@Mock 帮助我们解除了对外部系统（数据库、网络、文件系统）的依赖，创造了一个纯净的测试环境。
@InjectMocks 则通过自动依赖注入，简化了被测对象的创建过程，让我们专注于核心业务逻辑的验证。

理解它们之间的界限——一个是“假的替身”，一个是“被注入的主角”——是编写高质量 Java 单元测试的关键一步。通过合理地运用这两个注解，并结合我们在本文中讨论的最佳实践，你将能够构建出既稳健又易于维护的测试代码库。

现在，当你再次打开一个测试类时，希望你能自信地选择正确的注解，并清楚地知道它们在你的测试生命周期中扮演了什么角色。继续编码，继续测试！

投稿给我们	如何建站？
vps是什么？	如何安装宝塔？
如何通过博客赚钱？	便宜wordpress托管方案
免费wordpress主题	这些都是免费方案

豆丁博客