Mockito进阶：覆盖异常未抛出的测试场景

本文深入探讨了如何精准测试那些在 try-catch 中静默吞掉异常（不重新抛出）的业务方法——这类代码常因无法用传统 assertThrows 验证而被 Jacoco 标记为未覆盖，拖累整体覆盖率甚至阻塞 CI；文章直击痛点，提出以“验证可观测副作用”为核心的进阶策略：通过 Mockito Mock 日志器，精准断言异常发生后是否按预期记录错误日志，辅以可测性改造（如提取 package-private 委托方法、避免 static final Logger），不仅轻松达成 100% 分支覆盖，更真实保障了异常处理逻辑的健壮性与可观测性，让防御性编程真正经得起检验。

本文详解如何对 try-catch 中静默处理异常（不 re-throw）的方法进行有效单元测试，重点通过 Mock 日志器验证异常捕获逻辑，满足 Jacoco 行/分支覆盖率要求。

本文详解如何对 try-catch 中静默处理异常（不 re-throw）的方法进行有效单元测试，重点通过 Mock 日志器验证异常捕获逻辑，满足 Jacoco 行/分支覆盖率要求。

在真实业务场景中，许多方法（如 sendSuccessEmail）采用“防御性设计”：调用可能失败的外部服务（如邮件发送），并在 catch 块中仅记录错误、不传播异常。这类代码虽无显式抛出行为，但 Jacoco 等覆盖率工具会将 catch 分支标记为未覆盖——导致覆盖率下降，甚至阻塞 CI 流水线。

关键在于：我们无法用 assertThrows 验证“被吞掉的异常”，而应验证异常发生后系统的行为表现。最典型、最可靠的表现就是日志记录。

✅ 正确测试策略：Mock Logger + Verify Log Call

假设你的类使用 SLF4J（如 LoggerFactory.getLogger(YourClass.class)），且 logger 字段为 private final 成员：

public class EmailService {
    private final Logger logger = LoggerFactory.getLogger(EmailService.class);
    private final EmailServiceImpl emailServiceImpl;

    public EmailService(EmailServiceImpl emailServiceImpl) {
        this.emailServiceImpl = emailServiceImpl;
    }

    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) {
            logger.error("AR11 Application: Could not send success email due to error: ", e);
        }
    }

    // 委托方法（供 mock）
    void sendEmail(String host, Integer port, String from, String to, String subject, String body)
            throws MessagingException {
        emailServiceImpl.sendEmail(host, port, from, to, subject, body);
    }
}

? 注意：将 sendEmail 提取为 package-private（或 protected）方法，便于在测试中 when(...).thenThrow(...) —— 这是实现可控异常触发的前提。

✅ 完整 JUnit 5 + Mockito 测试示例

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;
import org.slf4j.Logger;

import static org.mockito.ArgumentMatchers.anyString;
import static org.mockito.Mockito.*;

@ExtendWith(MockitoExtension.class)
class EmailServiceTest {

    @Mock
    private EmailServiceImpl emailServiceImpl;

    @Mock
    private Logger logger; // 直接 mock Logger 实例（需确保构造时可注入）

    @Test
    void sendSuccessEmail_shouldLogErrorWhenSendFails() {
        // Given: 构造被测对象（需支持 Logger 注入，或使用 @Spy + doReturn）
        EmailService emailService = new EmailService(emailServiceImpl) {
            @Override
            protected void sendEmail(String host, Integer port, String from, String to,
                                     String subject, String body) throws MessagingException {
                throw new jakarta.mail.MessagingException("SMTP connection failed");
            }
        };

        // 或更推荐：使用 Spy + stubbing（若 logger 是 final 字段，需配合 @InjectMocks 或构造器注入）
        // EmailService emailService = spy(new EmailService(emailServiceImpl));
        // doThrow(new MessagingException("SMTP failure")).when(emailService)
        //     .sendEmail(any(), any(), any(), any(), any(), any());

        Ar11ResultBean resultBean = new Ar11ResultBean();
        resultBean.setRowsProcessed(123);

        // When: 执行被测方法（内部会触发异常并进入 catch）
        emailService.sendSuccessEmail(resultBean, "smtp.example.com", 587,
                "from@example.com", "to@example.com");

        // Then: 验证日志被精确调用一次，且包含预期前缀（不校验完整堆栈）
        verify(logger, times(1)).error(
                eq("AR11 Application: Could not send success email due to error: "),
                any(Throwable.class)
        );
    }
}

⚠️ 重要注意事项

• 不要 verify 异常本身：catch 块内无抛出，assertThrows 无效；也不要尝试 verify(emailServiceImpl).sendEmail(...) 后续调用——异常已中断执行流。
• 日志验证要精准：
  • 使用 eq("prefix") 匹配日志消息前缀（避免因换行/空格差异导致失败）；
  • 使用 any(Throwable.class) 捕获异常参数，切勿用 anyString() —— SLF4J 的 error(String, Throwable) 是重载方法，误用会导致 NoMatchingStubbingException。
• Logger 注入方式决定测试写法：
  • 若 logger 是 static final，需改用 @Spy + doAnswer 拦截日志调用，或使用 slf4j-test 等专用日志测试库；
  • 推荐将 Logger 改为非 static 成员，并通过构造器注入（提升可测性与 DI 友好性）。
• Jacoco 覆盖率确认：运行 mvn test jacoco:report，检查 sendSuccessEmail 方法的 catch 块是否显示为绿色（已覆盖）。

✅ 总结

测试「静默捕获异常」的唯一正解，是验证其可观测副作用——通常是日志、指标上报、状态更新或数据库写入。Mockito 的核心价值在此体现：它不关心异常是否被“吞”，而专注验证系统在异常发生后的确定性响应行为。坚持这一原则，即可高效达成 100% 分支覆盖率，同时保障异常处理逻辑的真实可靠性。

到这里，我们也就讲完了《Mockito进阶：覆盖异常未抛出的测试场景》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！