Mockito 单元测试进阶：如何覆盖「异常被捕获但不抛出」的代码分支

Mockito 单元测试进阶：如何覆盖「异常被捕获但不抛出」的代码分支

本文详解如何为 try-catch 中静默处理异常（如日志记录后吞掉异常）的方法编写有效单元测试，重点解决 jacoco 覆盖率缺口，通过 mock 日志器并验证 error() 调用实现 100% 异常路径覆盖。

在单元测试实践中，我们常常会遇到一种棘手的场景：一个业务方法，比如 `sendSuccessEmail`，内部采用了“防御式设计”。它会调用一个可能失败的依赖服务，但为了确保主流程的健壮性，选择用 try-catch 捕获所有异常，仅仅记录一条错误日志，而不是将异常抛给上游。这种设计本身没问题，但它却给单元测试出了个难题——异常压根就没逃出方法体，传统的 `assertThrows` 完全使不上劲。结果就是，Jacoco 这类覆盖率工具会无情地将整个 catch 块标记为红色，导致覆盖率报告上出现刺眼的缺口。

问题的核心其实在于测试思维的转变。我们不再需要关心“异常是否被抛出”，而是要验证当异常真的发生时，catch 块里预设的那些“副作用”是否如约执行了。最常见的副作用，就是日志记录。所以，测试策略必须从“状态断言”转向“行为验证”。

✅ 正确做法：Mock 日志器并验证 error() 调用

假设你的服务类使用 SLF4J 日志框架，并且日志器是通过静态字段声明的：

@Service
public class EmailService {
    private static final Logger log = LoggerFactory.getLogger(EmailService.class);

    public void sendSuccessEmail(Ar11ResultBean ar11ResultBean, String emailSmtpHost,
                                Integer emailSmtpPort, String emailAddressFrom, String emailAddressTo) {
        try {
            String emailBody = MessageFormat.format(Constants.EMAIL_BODY_SUCCESS,
                ar11ResultBean == null ? "" : ar11ResultBean.getRowsProcessed());
            sendEmail(emailSmtpHost, emailSmtpPort, emailAddressFrom, emailAddressTo,
                      Constants.EMAIL_SUBJECT_SUCCESS, emailBody);
        } catch (Exception e) {
            log.error("AR11 Application: Could not send success email due to error: ", e); // ← 这就是我们要验证的关键行为
        }
    }
    // ... sendEmail() 实现（可能抛出 MessagingException 等）
}

? 测试步骤（JUnit 5 + Mockito 5.x）

1. Mock 日志器字段：这是验证行为的前提，需要确保测试能控制这个日志对象。
2. Stub sendEmail() 抛出异常：模拟依赖方法失败，从而精准触发我们想要测试的 catch 分支。
3. 调用被测方法：执行 `sendSuccessEmail`，此时异常会被内部捕获。
4. 验证 log.error(...) 是否被精确调用一次，且消息前缀匹配：这才是测试通过的最终判据。

@ExtendWith(MockitoExtension.class)
class EmailServiceTest {
    @Mock
    private Logger logger; // 注意：需确保被测类中的 logger 字段可被注入或替换
    @Mock
    private EmailServiceImpl emailServiceImpl; // 假设 sendEmail 是其委托方法
    @InjectMocks
    private EmailService emailService;

    @Test
    void sendSuccessEmail_whenSendEmailThrowsException_thenLogsError() {
        // Given: 配置 sendEmail 抛出异常
        doThrow(new jakarta.mail.MessagingException("SMTP connection failed"))
            .when(emailServiceImpl)
            .sendEmail(anyString(), anyInt(), anyString(), anyString(), anyString(), anyString());

        // When: 执行被测方法（异常被捕获，无返回值）
        emailService.sendSuccessEmail(
            new Ar11ResultBean(), "smtp.example.com", 68, "from@test.com", "to@test.com"
        );

        // Then: 验证日志器被调用，且消息前缀正确（忽略异常对象本身，因 verify 不校验 varargs 第二参数）
        verify(logger, times(1)).error(
            eq("AR11 Application: Could not send success email due to error: ")
        );
        // ⚠️ 注意：SLF4J 的 error(String, Throwable) 是重载方法，Mockito 默认匹配第一个参数。
        // 若需严格验证异常对象，可使用 ArgumentCaptor：
        /*
        ArgumentCaptor captor = ArgumentCaptor.forClass(Throwable.class);
        verify(logger).error(anyString(), captor.capture());
        assertThat(captor.getValue()).isInstanceOf(MessagingException.class);
        */
    }
}

? 关键注意事项

• 日志器必须可 Mock：如果 logger 是 `private static final` 的，直接 Mockito 是无能为力的。这时候通常有两条路：
  • ✅ 推荐方案：将日志器改为非静态的成员变量，并通过构造器注入。这不仅是依赖注入的最佳实践，也让代码对测试更加友好。
  • ⚠️ 备选方案：当无法修改生产代码时，可以借助 mockito-inline 的 `MockedStatic` 来模拟静态方法。但这属于权宜之计，代码会稍显复杂：

    try (MockedStatic mocked = mockStatic(LoggerFactory.class)) {
        Logger mockLogger = mock(Logger.class);
        mocked.when(() -> LoggerFactory.getLogger(EmailService.class)).thenReturn(mockLogger);
        // ... 后续验证
    }

• verify 匹配精度：`log.error(String, Throwable)` 的第二个参数是可变参数，Mockito 的 `verify` 默认只校验第一个 `String` 参数。如果你需要断言抛出的异常具体是什么类型，务必使用 `ArgumentCaptor` 来捕获并断言。
• Jacoco 覆盖逻辑：采用上述方案后，catch 块内的每行代码都会被成功执行，从而满足 Jacoco 的语句覆盖和分支覆盖要求，轻松通过 CI/CD 流水线中的质量门禁。
• 避免反模式：千万别试图去“模拟异常被捕获”这个动作本身（比如对 `Exception.class` 进行打桩）。Mockito 不支持对异常类型直接打桩；异常必须由你模拟的依赖方法真实地抛出，然后由被测方法内部的 catch 块真实地捕获。

✅ 总结

为 try-catch 静默处理逻辑编写单元测试，其核心思想可以归结为一句话：将“异常处理”视为一种可观测的、有副作用的行为（比如写日志、发指标、改状态），而不是一个不可见的控制流黑洞。通过 Mock 那些与外部协作的对象（邮件客户端、日志器、指标上报器），精准地触发 catch 分支，并严格验证这些副作用是否发生，你就能写出既可靠又具备高覆盖率的单元测试。这不仅仅是一项测试技术，更是面向可观测性进行系统设计这一思维的生动体现。