本文详解如何通过 Mockito 模拟 InetAddress.getLocalHost() 抛出异常，结合 @SneakyThrows 的实际行为，编写可覆盖异常分支的单元测试，并推荐使用 AssertJ 进行更精准的异常断言。
本文详解如何通过 mockito 模拟 `inetaddress.getlocalhost()` 抛出异常，结合 `@sneakythrows` 的实际行为，编写可覆盖异常分支的单元测试，并推荐使用 assertj 进行更精准的异常断言。
@SneakyThrows（来自 Lombok）的作用是绕过 Java 编译期的受检异常检查，它不会捕获或处理异常，而是将受检异常（如 UnknownHostException）以运行时异常方式抛出。因此，要测试其异常路径，关键不是“测试注解本身”，而是确保被修饰的方法在底层调用真实抛出异常时，能透传该异常并被正确捕获。
在你的示例中，getLocalHostName() 方法本质调用的是 InetAddress.getLocalHost().getHostName() —— 该调用可能抛出 UnknownHostException（受检异常），而 @SneakyThrows 使其无需 try-catch 或 throws 声明即可传播。因此，测试目标应为：当 InetAddress.getHostName() 抛出异常时，getLocalHostName() 是否原样抛出（包装为 RuntimeException）？
✅ 正确做法是：不 mock InetAddress.getLocalHost()（该静态方法难以直接 mock），而是重构测试逻辑，让被测方法委托给可 mock 的实例（如你已做的 mockInetAddress），再控制该实例行为。
以下是完整、可运行的测试方案：
✅ 推荐测试结构（基于你的现有代码优化）
@ExtendWith(MockitoExtension.class)
class MyRepositoryImplTest {
@Mock(lenient = true)
private NamedParameterJdbcTemplate jdbcTemplate;
@Mock(lenient = true)
private InetAddress mockInetAddress; // 可控的 InetAddress 实例
@Test
void testGetLocalHostName_success() {
String expectedHostname = "test-host";
Mockito.when(mockInetAddress.getHostName()).thenReturn(expectedHostname);
// 构造被测对象：覆写方法，使其返回 mockInetAddress 的结果
MyRepository repository = new MyRepository(jdbcTemplate) {
@Override
public String getLocalHostName() {
return mockInetAddress.getHostName(); // 不再调用静态方法！
}
};
assertThat(repository.getLocalHostName()).isEqualTo(expectedHostname);
}
@Test
void testGetLocalHostName_throwsUnknownHostException() {
// 模拟 getHostName() 抛出受检异常（实际生产中可能发生）
Mockito.when(mockInetAddress.getHostName())
.thenThrow(new UnknownHostException("Failed to resolve local host"));
MyRepository repository = new MyRepository(jdbcTemplate) {
@Override
public String getLocalHostName() {
return mockInetAddress.getHostName();
}
};
// @SneakyThrows 会将 UnknownHostException 包装为 RuntimeException（默认为 UndeclaredThrowableException）
// 但更稳妥的做法是断言原始异常类型（AssertJ 支持）
assertThatThrownBy(repository::getLocalHostName)
.isInstanceOf(UnknownHostException.class)
.hasMessage("Failed to resolve local host");
}
}
⚠️ 注意事项与最佳实践
- 不要尝试 mock 静态方法 InetAddress.getLocalHost()：JUnit 5 + Mockito 默认不支持 mock 静态方法；若必须，需引入 mockito-inline 并启用 @MockedStatic，但会增加复杂度且违背测试简洁性原则。委托模式（如上）更可控、更符合测试隔离原则。
- @SneakyThrows 的异常类型：Lombok 默认将受检异常包装为 UndeclaredThrowableException（继承自 RuntimeException）。若需精确断言原始异常，优先使用 AssertJ 的 isInstanceOf(OriginalException.class)（它会自动解包）。
- 确保测试覆盖真实异常场景：UnknownHostException 是典型触发条件（如 DNS 配置错误、hosts 文件缺失、网络不可达），应在测试中显式模拟，而非依赖环境偶然触发。
- 避免 assertThrows(Exception.class, ...) 的宽泛断言：它无法区分业务异常与底层系统异常，降低测试可靠性；应明确预期异常类型（如 UnknownHostException）。
✅ 补充：使用 AssertJ 的优势（推荐添加依赖）
<!-- Maven --> <dependency><groupid>org.assertj</groupid><artifactid>assertj-core</artifactid><version>3.24.0</version><scope>test</scope></dependency>
AssertJ 提供链式断言、自动异常解包、消息校验等能力，显著提升异常测试的可读性与健壮性。
综上，覆盖 @SneakyThrows 的核心在于控制被修饰方法的实际执行路径，使其在测试中主动抛出目标受检异常，并验证该异常是否被正确透传——这本质上是对方法行为的测试，而非对 Lombok 注解的测试。
