Spring Boot 单元测试中正确注入 @Value 配置属性的完整指南

在 Spring Boot 的 Mockito 单元测试中，@Value 注入的配置属性（如 aws.s3.bucketName）为 null，根本原因是 Spring 容器未启动、配置文件未加载；解决方法是使用 @SpringBootTest 启动最小上下文，并配合 @TestConfiguration 或 @TestPropertySource 显式提供配置。

相信不少开发者在写 Spring Boot 单元测试时都踩过这个坑：明明在 `application.yml` 里配得好好的 `aws.s3.bucketName`，一到测试里用 `@Value` 注入，拿到的却总是 `null`。这问题看似简单，背后却直指单元测试的一个核心选择：你到底是在测“纯逻辑”，还是在测“框架集成”？

问题的根源很明确：当你使用纯 `@MockitoExtension` 进行单元测试时，Spring 的依赖注入容器（IoC Container）是完全不参与工作的。`@InjectMocks` 注解只是通过反射和 Mockito 的内部机制帮你把测试对象实例化出来，它可不会去解析 `@Value`，更不会主动加载你的配置文件。结果就是，所有依赖 `@Value` 注入的字段都保持着它们的默认值（比如 String 就是 null），运行时抛出 `NullPointerException` 或者业务逻辑异常，也就不奇怪了。

✅ 正确做法：启用轻量级 Spring 上下文

最直接有效的解决方案，就是让 Spring 容器动起来。推荐使用 `@SpringBootTest` 注解，并通过它的 `classes` 属性指定测试所需的最小组件集合。这样做会启动一个嵌入式的 Spring 应用上下文，自动加载 `application.yml` 中的配置，并完成 `@Value`、`@Autowired` 等注解的解析与注入。

@ExtendWith(MockitoExtension.class)
@SpringBootTest(classes = {
    AsyncPublisherServiceImpl.class,
    AsyncPublisherDao.class, // 或使用 @MockBean 替代 @Mock
    AsyncUtil.class,
    ClientListenerService.class
})
@MockitoSettings(strictness = Strictness.LENIENT)
class AsyncPublisherServiceImplTest {
    @Autowired
    private AsyncPublisherServiceImpl asyncPublisherServiceImpl;
    @MockBean
    private AsyncPublisherDao dao;
    @MockBean
    private AsyncUtil asyncUtil;
    @MockBean
    private ClientListenerService techpulseservice;
    @Test
    void publish() {
        // 提前配置 mock 行为
        when(dao.isValidCount(ConstantsTest.UUID)).thenReturn(true);
        when(asyncUtil.generateZip(anyString(), anyList())).thenReturn(new byte[0]);
        File file = new File(AsyncUtil.sanitizePathandfilename(ConstantsTest.UUID + ".zip"));
        try {
            FileUtils.writeByteArrayToFile(file, new byte[0]);
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
        // 执行被测方法（此时 bucketName 已由 Spring 注入）
        boolean result = asyncPublisherServiceImpl.publish(ConstantsTest.UUID, ConstantsTest.UnitOfWorkId);
        assertThat(result).isTrue();
        verify(dao).updateLink(eq(ConstantsTest.UUID), anyString());
    }
}

⚠️ 关键注意事项

采用 `@SpringBootTest` 方案时，有几个细节必须留意，否则很容易引入新的问题。

避免混用 @Mock 和 @SpringBootTest

这是一个常见的误区。来自 Mockito 的 `@Mock` 注解与 Spring 的测试上下文是不兼容的。正确的做法是使用 Spring Test 提供的 `@MockBean`。它由 Spring 容器管理，不仅能精准替换掉上下文中的 Bean，还支持 `@SpyBean`、重置等更高级的测试能力。

配置文件必须可达

确保 `src/test/resources/application.yml` 这个文件确实存在，并且包含了有效的配置。例如：

aws:
  s3:
    bucketName: "test-bucket"
    region: "us-west-2"

如果你需要覆盖生产环境的配置，或者不想依赖外部文件，还可以使用 `@TestPropertySource` 注解直接在测试类上声明属性：`@TestPropertySource(properties = {"aws.s3.bucketName=test-bucket"})`。

性能权衡与替代方案

必须承认，`@SpringBootTest` 启动一个 Spring 上下文，其速度肯定比纯 Mockito 测试要慢。如果你的测试目标仅仅是验证一段不依赖真实配置的业务逻辑，那么还有一个更轻量级的方案：手动设置字段值。

@BeforeEach
void setUp() {
    ReflectionTestUtils.setField(asyncPublisherServiceImpl, "bucketName", "test-bucket");
}

利用 Spring 测试工具包里的 `ReflectionTestUtils`，你可以直接绕过 Spring 的生命周期，给私有字段赋值。这种方法非常快，适用于简单的场景。但它的缺点也很明显：它完全避开了 Spring 的初始化流程，如果被测 Service 的构造过程很复杂（比如依赖 `@PostConstruct` 方法），这种方式就可能遗漏关键环节，因此不推荐在复杂场景下使用。

? 总结

说到底，`@Value` 是 Spring 框架层面的功能，脱离了 Spring 容器自然就失效了。这其实提醒我们，在编写单元测试时，首先要明确自己的测试范式：是追求速度的“纯逻辑”测试（用纯 Mockito），还是追求真实性的“集成”测试（用 Spring Boot Test）。对于涉及配置注入、事务管理、AOP 切面等 Spring 特性的 Service 层测试，`@SpringBootTest` 配合 `@MockBean` 是目前业界标准且可靠的实践。选择哪种方式，取决于你对测试速度和测试覆盖范围之间的权衡。