本文详解如何对 try-catch 中静默处理异常（如日志记录后吞掉异常）的方法进行有效单元测试，重点解决 jacoco 覆盖率缺口，通过 mockito 模拟异常触发 + 验证日志调用实现 100% 分支覆盖。
本文详解如何对 try-catch 中静默处理异常（如日志记录后吞掉异常）的方法进行有效单元测试，重点解决 jacoco 覆盖率缺口，通过 mockito 模拟异常触发 + 验证日志调用实现 100% 分支覆盖。
在真实业务场景中，许多关键方法（如 sendSuccessEmail）采用“防御式设计”：内部调用可能失败的依赖服务（如邮件发送），但选择捕获所有异常、记录错误日志后不向上抛出，以保障主流程稳定性。这类代码虽无显式 throws 声明，却极易因未被测试覆盖而成为 Jacoco 报告中的红色分支（catch 块未执行），影响质量门禁。
要实现对该 catch 分支的完整测试，核心思路不是“断言异常被抛出”，而是 主动触发异常 → 验证异常是否被正确捕获并按预期处理。由于目标方法本身不抛出异常，传统 assertThrows 或 @Test(expected=...) 完全失效，必须转向行为验证（Behavior Verification）。
✅ 正确做法：Mock 外部依赖 + 触发异常 + 验证日志
假设 sendSuccessEmail 内部调用了 sendEmail(...)（该方法会抛出 MessagingException），且类中注入了 SLF4J Logger：
public class EmailServiceImpl {
private final Logger log = LoggerFactory.getLogger(EmailServiceImpl.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);
}
}
// 可被 mock 的受保护/包级/或通过 @Mock 注入的依赖方法
void sendEmail(String host, Integer port, String from, String to, String subject, String body)
throws MessagingException {
// 真实实现...
}
}对应单元测试（JUnit 5 + Mockito 5.x）如下：
@ExtendWith(MockitoExtension.class)
class EmailServiceImplTest {
@Mock
private Logger logger; // 注意：需使用 mockito-slf4j 或自定义 MockLogger，见下方说明
@Mock
private EmailServiceImpl emailServiceSpy; // 或更推荐：@InjectMocks + @Spy 组合
@Test
void sendSuccessEmail_shouldLogErrorWhenSendFails() {
// Given: 构造测试数据
Ar11ResultBean resultBean = new Ar11ResultBean();
resultBean.setRowsProcessed(123);
// 使用 @Spy 包裹真实实例，并 stub sendEmail 方法抛出异常
EmailServiceImpl service = spy(new EmailServiceImpl());
doThrow(new MessagingException("SMTP connection failed"))
.when(service).sendEmail(
anyString(), anyInt(), anyString(), anyString(), anyString(), anyString()
);
// 将 mock logger 注入到 service（若 logger 是 final 字段，需用 @MockedStatic 或构造器注入）
// ⚠️ 关键：SLF4J Logger 默认无法直接 mock —— 推荐方案见下方注意事项
// When: 执行被测方法（不会抛出异常）
service.sendSuccessEmail(resultBean, "smtp.example.com", 587,
"from@example.com", "to@example.com");
// Then: 验证日志 error 方法被调用，且含预期前缀消息（忽略异常对象参数）
verify(logger).error(eq("AR11 Application: Could not send success email due to error: "), any(Throwable.class));
}
}⚠️ 重要注意事项
-
Logger Mock 限制：SLF4J 的 Logger 是 final 类，不能直接 mock(Logger.class)。推荐方案：
- ✅ 最佳实践：将 Logger 改为可注入依赖（如通过构造器传入 Supplier<Logger> 或接口抽象），便于测试；
- ✅ 快速适配：使用 mockito-slf4j 扩展库，自动提供 @Mock Logger logger 支持；
- ⚠️ 不推荐：Mockito.mockStatic(LoggerFactory.class)（PowerMockito 风格），侵入性强、维护成本高。
避免 verify(...).error(anyString())：仅校验字符串字面量会忽略异常参数传递，应使用 any(Throwable.class) 显式声明日志记录了异常对象，确保 catch 块真正执行了完整逻辑。
Jacoco 覆盖原理：此测试强制执行 try 块（触发 sendEmail）→ 进入 catch → 执行 log.error(...) → 流程正常结束。Jacoco 将标记 catch 分支为已覆盖，消除红色高亮。
? 总结
测试「异常被捕获」逻辑的本质，是驱动程序进入该分支并验证其副作用（如日志、状态变更、指标上报等），而非关注异常本身。Mockito 的 doThrow() + verify() 组合是标准解法；配合现代测试实践（依赖注入、可测性设计），可高效达成 100% 异常处理分支覆盖率，兼顾代码健壮性与工程可维护性。
