Spring Boot 单元测试进阶：Mockito 模拟 ItemBusinessService 的 3 种策略

老李校长

253人浏览 · 2026-07-08 12:27:57

老李校长 · 2026-07-08 12:27:57 发布

Spring Boot 单元测试进阶：Mockito 模拟 ItemBusinessService 的 3 种策略

在 Spring Boot 应用的开发过程中，单元测试是确保代码质量的关键环节。特别是对于依赖外部服务的业务逻辑层，如何有效地隔离测试目标与外部依赖，是每个开发者都需要掌握的技能。本文将深入探讨三种不同的 Mockito 模拟策略，帮助你在不同测试场景下做出合适的选择。

1. 测试环境准备与基础概念

在开始之前，我们需要明确几个核心概念。单元测试的目标是验证单个代码单元（通常是一个方法）的行为是否符合预期，而 Mock 测试则是通过创建虚拟对象来模拟真实依赖的行为。

对于 Spring Boot 应用，典型的测试场景可能涉及以下组件：

@RestController
public class ItemController {
    @Autowired
    private ItemBusinessService businessService;
    
    @GetMapping("/all-items-from-database")
    public List<Item> retrieveAllItems() {
        return businessService.retrieveAllItems();
    }
}

在这个例子中， ItemController 依赖于 ItemBusinessService 。为了单独测试控制器的行为，我们需要模拟业务服务。

关键测试注解对比 ：

注解	作用范围	Spring 上下文	适用场景
`@Mock`	单个测试类	不启动	纯 Mockito 测试
`@MockBean`	整个测试	启动	Spring Boot 测试
`@InjectMocks`	单个测试类	不启动	依赖注入测试

提示：选择哪种模拟策略取决于你是否需要 Spring 容器的支持。集成测试通常需要 @MockBean ，而纯单元测试则可以使用 @Mock 和 @InjectMocks 。

2. 使用 @MockBean 的 Spring Boot 集成测试

@MockBean 是 Spring Boot 测试框架提供的特殊注解，它会在 Spring 应用上下文中注册一个 Mock 对象，替代原有的 Bean。这种方式适合需要部分真实 Spring 环境的测试场景。

典型测试类结构 ：

@SpringBootTest
@AutoConfigureMockMvc
class ItemControllerIntegrationTest {
    @Autowired
    private MockMvc mockMvc;
    
    @MockBean
    private ItemBusinessService businessService;
    
    @Test
    void retrieveAllItems_shouldReturnMockedItems() throws Exception {
        // 准备测试数据
        List<Item> mockItems = Arrays.asList(
            new Item(1, "Item 1", 10, 100),
            new Item(2, "Item 2", 20, 200)
        );
        
        // 配置 Mock 行为
        when(businessService.retrieveAllItems()).thenReturn(mockItems);
        
        // 执行并验证
        mockMvc.perform(get("/all-items-from-database"))
               .andExpect(status().isOk())
               .andExpect(jsonPath("$", hasSize(2)))
               .andExpect(jsonPath("$[0].name", is("Item 1")));
    }
}

@MockBean 的核心特点 ：

与 Spring 测试框架深度集成
适用于控制器层测试，可以模拟服务层
支持自动注入到 Spring 管理的组件中
测试结束后会自动重置

实际应用中的注意事项 ：

当测试需要部分真实 Spring 环境（如 MVC 层）时，这是最佳选择
测试执行速度比纯单元测试慢，因为需要启动部分 Spring 上下文
适合验证控制器与 HTTP 层的交互

3. 使用 @Mock + @InjectMocks 的纯单元测试

对于不需要 Spring 环境的纯业务逻辑测试， @Mock 和 @InjectMocks 组合提供了更轻量级的解决方案。这种方式完全基于 Mockito 框架，不依赖 Spring 容器。

典型测试示例 ：

class ItemControllerUnitTest {
    @Mock
    private ItemBusinessService businessService;
    
    @InjectMocks
    private ItemController itemController;
    
    @BeforeEach
    void setUp() {
        MockitoAnnotations.openMocks(this);
    }
    
    @Test
    void retrieveAllItems_shouldReturnItemsFromService() {
        // 准备测试数据
        List<Item> expectedItems = List.of(
            new Item(1, "Test Item", 5, 50)
        );
        
        // 配置 Mock 行为
        when(businessService.retrieveAllItems()).thenReturn(expectedItems);
        
        // 执行测试
        List<Item> actualItems = itemController.retrieveAllItems();
        
        // 验证结果
        assertEquals(expectedItems, actualItems);
        verify(businessService).retrieveAllItems();
    }
}

这种方式的优势 ：

测试执行速度极快，无需启动 Spring 上下文
完全隔离被测试类及其依赖
适合测试业务逻辑复杂的服务层
可以精细控制每个依赖的行为

常见问题解决方案 ：

构造函数注入问题 ：如果使用构造函数注入而非字段注入，需要手动创建测试实例：

@BeforeEach
void setUp() {
    businessService = mock(ItemBusinessService.class);
    itemController = new ItemController(businessService);
}

静态方法模拟 ：需要额外配置 Mockito：

@BeforeAll
static void setUp() {
    Mockito.mockStatic(SomeStaticClass.class);
}

4. 手动 Mock 与构造函数注入策略

对于追求更高测试纯净度的项目，手动创建 Mock 对象并通过构造函数注入是另一种选择。这种方式不依赖任何框架注解，完全由开发者控制对象的创建和依赖关系。

实现示例 ：

class ItemControllerManualMockTest {
    private ItemBusinessService businessService;
    private ItemController itemController;
    
    @BeforeEach
    void setUp() {
        businessService = mock(ItemBusinessService.class);
        itemController = new ItemController(businessService);
    }
    
    @Test
    void retrieveAllItems_withEmptyList_shouldReturnEmpty() {
        // 配置 Mock 返回空列表
        when(businessService.retrieveAllItems()).thenReturn(Collections.emptyList());
        
        // 执行并验证
        assertTrue(itemController.retrieveAllItems().isEmpty());
    }
}

手动 Mock 的核心价值 ：

完全控制测试环境，没有魔法注解
强制使用构造函数注入，促进更好的设计
测试代码更显式，易于理解
适合简单类或对框架有严格限制的项目

与注解方式的对比 ：

特性	手动 Mock	注解方式
代码量	较多	较少
灵活性	高	中
可读性	显式	隐式
框架依赖	无	需要 Mockito

5. 三种策略的对比与选型建议

为了帮助你在实际项目中做出选择，下面从多个维度比较这三种策略：

功能对比表 ：

特性	@MockBean	@Mock+@InjectMocks	手动 Mock
需要 Spring 上下文	是	否	否
执行速度	慢	快	最快
适合测试层级	控制器	服务/控制器	任何
代码复杂度	低	中	高
框架依赖	Spring+Mockito	Mockito	无
适合场景	集成测试	单元测试	纯单元测试