本文探讨了在单元测试中如何处理和测试方法内部被捕获并记录日志而非重新抛出的异常。我们将分析此类设计对测试的影响，并提供多种解决方案，包括通过重构代码以提高可测试性（如重新抛出异常或返回状态指示）、以及在特定场景下如何测试日志输出或验证异常是否被正确捕获，最终强调设计可测试代码的重要性。
引言：理解内部捕获异常的测试挑战
在软件开发中，我们经常会遇到这样的场景：一个方法调用了另一个可能抛出异常的方法，但被调用的方法内部捕获了异常并进行了处理（例如，仅仅记录日志），而没有将异常重新抛出。这使得外部调用者无法直接感知到异常的发生，也给单元测试带来了挑战。
考虑以下Java代码示例：
// Class A
public class A {
private static Logger logger = LoggerFactory.getLogger("A");
private B b;
public A() {
b = new B();
}
public void methodA() {
b.methodB();
logger.info("A");
}
}
// Class B
public class B {
private static Logger logger = LoggerFactory.getLogger("B");
public B() {
}
public void methodB() {
try {
throw new Exception("NULL"); // 内部抛出异常
} catch(Exception e) {
logger.info("Exception thrown"); // 异常被捕获并记录日志
}
}
}当我们尝试测试 methodB 内部抛出的异常时，直接使用 assertThrows 会失败：
// 原始测试代码
@Test
public void testException() {
A a = new A();
a.methodA(); // 调用 methodA，其内部调用 methodB
// 此处尝试断言 b.methodB() 抛出异常，但实际上异常已被 methodB 内部捕获
// 注意：这里的 b 实例未被直接访问，如果想测试 methodB，需要直接调用 B 的实例
// 假设我们想测试 B.methodB() 的异常行为
B bInstance = new B();
assertThrows(Exception.class, () -> bInstance.methodB());
}上述测试会产生以下错误：
Expected java.lang.Exception to be thrown, but nothing was thrown. org.opentest4j.AssertionFailedError: Expected java.lang.Exception to be thrown, but nothing was thrown.
这是因为 methodB 中的 try-catch 块已经捕获了 Exception("NULL")，并将其处理掉（仅记录日志），导致异常没有向上层调用者（包括测试框架）传播。assertThrows 期望代码块抛出异常，但由于异常被“吞噬”了，因此断言失败。
问题分析：为何直接断言异常会失败？
assertThrows 是 JUnit 5 提供的一个强大工具，用于验证特定代码块是否抛出了预期的异常。它的工作原理是执行提供的 Lambda 表达式，并检查该表达式执行过程中是否有指定类型的异常被抛出。如果抛出了异常，测试通过；如果没有，或者抛出了不同类型的异常，测试失败。
在上述 Class B 的设计中，methodB 内部的 try-catch 结构是导致 assertThrows 失效的根本原因。catch 块捕获了 new Exception("NULL")，然后执行了 logger.info("Exception thrown")。这意味着，当 methodB 执行完毕时，它以正常流程结束，没有任何异常向其调用者传播。对于 assertThrows 而言，它观察到的是一个“无异常”的执行路径，自然会报告“没有抛出异常”。
这种“静默吞噬”异常的设计模式通常被认为是一种反模式，因为它隐藏了潜在的问题，使得调试和测试变得困难。在大多数情况下，如果一个方法内部发生了异常，它应该：
- 重新抛出异常：让调用者知道发生了错误，并由调用者决定如何处理。
- 抛出包装后的业务异常：将底层技术异常转换为更具业务意义的异常，向上层传递。
- 返回错误状态或 Optional 类型：明确告知调用者操作失败，并提供失败原因。
解决方案一：优化代码设计以提高可测试性（推荐）
最根本且推荐的解决方案是修改被测试的代码，使其设计更具可测试性。
策略 A：重新抛出异常或抛出特定业务异常
让异常向上冒泡，或者将其包装成更具业务意义的异常并抛出。这样，外部调用者和测试框架就能直接捕获并断言这些异常。
修改 Class B：
public class B {
private static Logger logger = LoggerFactory.getLogger("B");
public B() {
}
public void methodB() throws CustomBusinessException { // 声明抛出异常
try {
// 模拟可能抛出异常的业务逻辑
if (true) { // 假设某种条件触发异常
throw new IllegalArgumentException("Invalid parameter for B");
}
} catch(IllegalArgumentException e) {
logger.error("Error in methodB: {}", e.getMessage());
// 将内部异常包装成业务异常并重新抛出
throw new CustomBusinessException("Failed to process in B", e);
}
}
}
// 自定义业务异常类
class CustomBusinessException extends Exception {
public CustomBusinessException(String message) {
super(message);
}
public CustomBusinessException(String message, Throwable cause) {
super(message, cause);
}
}修改测试代码：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertThrows;
import static org.junit.jupiter.api.Assertions.assertTrue;
public class BTest {
@Test
public void testMethodBThrowsCustomBusinessException() {
B b = new B();
// 断言 methodB 会抛出 CustomBusinessException
CustomBusinessException thrown = assertThrows(
CustomBusinessException.class,
() -> b.methodB(),
"Expected methodB() to throw CustomBusinessException, but it didn't"
);
// 进一步验证异常信息或原因
assertTrue(thrown.getMessage().contains("Failed to process in B"));
assertTrue(thrown.getCause() instanceof IllegalArgumentException);
}
}策略 B：返回状态指示或 Optional 类型
如果业务逻辑不希望通过异常来中断流程，而是希望通过返回值来告知操作结果，可以使用 Optional 类型或自定义状态对象。
修改 Class B：
import java.util.Optional;
public class B {
private static Logger logger = LoggerFactory.getLogger("B");
public B() {
}
// 返回 Optional<String>，表示操作结果
public Optional<String> methodBWithStatus() {
try {
// 模拟可能抛出异常的业务逻辑
if (true) { // 假设某种条件触发异常
throw new RuntimeException("Internal error in B");
}
// 正常情况下返回一个值
return Optional.of("Success");
} catch(RuntimeException e) {
logger.error("Exception caught in methodBWithStatus: {}", e.getMessage());
// 异常发生时返回一个空的 Optional
return Optional.empty();
}
}
// 或者返回一个自定义结果对象
public OperationResult methodBWithResult() {
try {
if (true) { // 假设某种条件触发异常
throw new IllegalStateException("State error in B");
}
return new OperationResult(true, "Operation successful");
} catch (Exception e) {
logger.error("Exception caught in methodBWithResult: {}", e.getMessage());
return new OperationResult(false, "Operation failed: " + e.getMessage());
}
}
}
class OperationResult {
private final boolean success;
private final String message;
public OperationResult(boolean success, String message) {
this.success = success;
this.message = message;
}
public boolean isSuccess() {
return success;
}
public String getMessage() {
return message;
}
}修改测试代码：
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertFalse;
import static org.junit.jupiter.api.Assertions.assertTrue;
public class BTest {
@Test
public void testMethodBWithStatusReturnsEmptyOptionalOnError() {
B b = new B();
Optional<String> result = b.methodBWithStatus();
// 断言返回的是一个空的 Optional，表示操作失败
assertFalse(result.isPresent(), "Expected methodBWithStatus to return empty Optional on error");
}
@Test
public void testMethodBWithResultReturnsFailureStatusOnError() {
B b = new B();
OperationResult result = b.methodBWithResult();
// 断言返回结果表示失败
assertFalse(result.isSuccess(), "Expected methodBWithResult to indicate failure");
assertTrue(result.getMessage().contains("Operation failed"));
}
}解决方案二：测试日志输出（慎用）
如果由于遗留代码或其他限制，无法修改被测试的代码以重新抛出异常或返回状态，那么可以考虑测试日志输出。这种方法通常不被推荐，因为它将测试与日志实现细节耦合，可能导致测试脆弱且难以维护。然而，在特定场景下，这可能是唯一的测试途径。
要测试日志输出，你需要：
- 配置日志框架：使其输出到可捕获的地方（例如，内存中的 Appender）。
- 使用测试工具：例如，Logback 提供了 ListAppender，或者可以使用 Mockito 模拟日志器。
概念性示例（使用 Logback 的 ListAppender）：
import ch.qos.logback.classic.Logger;
import ch.qos.logback.classic.spi.ILoggingEvent;
import ch.qos.logback.core.read.ListAppender;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.slf4j.LoggerFactory;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertTrue;
public class BLogTest {
private ListAppender<ILoggingEvent> listAppender;
private Logger logger;
@BeforeEach
public void setup() {
// 获取 Class B 内部使用的 Logger 实例
logger = (Logger) LoggerFactory.getLogger("B");
listAppender = new ListAppender<>();
listAppender.start();
logger.addAppender(listAppender);
}
@AfterEach
public void teardown() {
logger.detachAppender(listAppender);
listAppender.stop();
}
@Test
public void testMethodBLogsExceptionMessage() {
B b = new B();
b.methodB(); // 调用 methodB，它会捕获异常并记录日志
// 断言日志列表中包含预期的日志事件
assertEquals(1, listAppender.list.size(), "Expected one log entry");
ILoggingEvent loggingEvent = listAppender.list.get(0);
assertTrue(loggingEvent.getMessage().contains("Exception thrown"), "Log message should indicate exception");
// 可以进一步检查日志级别、异常信息等
// assertEquals(Level.INFO, loggingEvent.getLevel()); // 原始代码是 info
}
}注意事项：
- 这种方法高度依赖日志框架的实现细节。
- 测试可能会因为日志格式、日志级别或日志消息的微小变化而失败。
- 它实际上是在测试副作用（日志），而不是直接测试核心业务逻辑的异常行为。
解决方案三：验证异常被正确捕获（特定场景）
如果业务逻辑明确要求某个异常必须被内部捕获（即“吞噬”），并且不应该向上层传播，那么测试的重点就变成了验证这个“吞噬”行为是否按预期发生。换句话说，我们测试的是：如果内部发生异常，它是否被正确捕获了，并且没有导致测试失败（除非是意外的未捕获异常）。
这种测试的思路是：如果 methodB 内部抛出了异常但被捕获，那么 methodB 的调用应该正常返回。如果 methodB 没有捕获异常（例如，try-catch 块被意外移除），那么异常会向上冒泡，导致测试失败。
测试代码示例：
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.fail;
public class BSwallowedExceptionTest {
@Test
public void testMethodBSwallowsExceptionAsExpected() {
B b = new B();
try {
b.methodB(); // 调用 methodB，预期它会捕获内部异常并正常返回
// 如果代码执行到这里，说明 methodB 成功捕获了内部异常，并正常结束
// 这是一个成功的场景，无需进一步断言
} catch (Exception e) {
// 如果 methodB 没有捕获异常，或者抛出了其他未预期的异常，
// 那么测试应该失败，因为我们期望异常被“吞噬”
fail("Method B unexpectedly threw an exception: " + e.getMessage());
}
}
}在这个测试中，我们期望 b.methodB() 能够顺利执行完毕，而不会抛出任何异常。如果它真的抛出了异常，那么 catch 块会被触发，并通过 fail() 方法明确指出测试失败，因为这违反了“异常应该被吞噬”的预期。
总结与最佳实践
测试内部捕获的异常是一个常见的挑战，但通过适当的设计和测试策略，可以有效地解决。
- 优先重构代码（推荐）：这是最根本的解决方案。避免“静默吞噬”异常，除非有充分的理由。通过重新抛出更具体的异常、使用 Optional 或返回状态对象，可以显著提高代码的可测试性和可维护性。
- 设计可测试的代码：在编写代码时，就应该考虑到如何对其进行测试。异常处理逻辑是代码行为的重要组成部分，其行为应该清晰、可预测且易于验证。
- 慎用日志测试：虽然测试日志输出在某些极端情况下是可行的，但应将其作为最后的手段。它通常会引入不必要的耦合，并使测试变得脆弱。
- 明确测试意图：在编写测试之前，明确你想要测试的是什么。是异常的发生？异常被捕获？还是异常被处理后的结果？根据不同的意图选择最合适的测试方法。
通过遵循这些原则，开发者可以构建出更健壮、更易于理解和维护的软件系统。
