Lombok 的 @SneakyThrows 注解具有 SOURCE 级保留策略，编译后即被擦除，无法通过反射获取；正确验证方式是检测其运行时行为：方法能否抛出受检异常，且该异常未在 throws 子句中声明。
如何测试 lombok @sneakythrows 注解的存在性？lombok 的 `@sneakythrows` 注解具有 `source` 级保留策略，编译后即被擦除，无法通过反射获取；正确验证方式是检测其**运行时行为**：方法能否抛出受检异常，且该异常未在 `throws` 子句中声明。
Lombok 的 @SneakyThrows 是一个编译期增强注解，其核心作用是绕过 Java 的受检异常（checked exception）强制声明机制：它让方法在不显式声明 throws 的前提下，仍能合法抛出受检异常（如 IOException、SQLException），由 Lombok 在编译时自动插入字节码级的 try-catch-throw 包装逻辑。
由于 @SneakyThrows 的元注解定义为 @Retention(RetentionPolicy.SOURCE)，它仅存在于源码阶段，不会写入 .class 文件，因此任何基于运行时反射的检查（如 method.getAnnotation(SneakyThrows.class)）必然返回 null —— 这不是你的代码问题，而是设计使然。
✅ 正确的单元测试思路是：验证其语义效果，而非注解存在本身。即验证两个关键契约：
- 方法实际能抛出指定受检异常（运行时行为）；
- 该异常未出现在方法签名的 throws 列表中（编译期契约）。
以下是一个完整、可复用的 JUnit 5 测试示例：
import org.junit.jupiter.api.Test;
import java.io.IOException;
import static org.junit.jupiter.api.Assertions.*;
import static java.util.Arrays.asList;
class SneakyThrowsTest {
@Test
void myMethod_hasSneakyThrowsForIOException() throws NoSuchMethodException {
// ✅ 行为验证：调用方法应抛出 IOException
assertThrows(IOException.class, this::myMethod);
// ✅ 契约验证：方法签名中不声明 IOException
Class<?>[] declaredExceptions = getClass()
.getMethod("myMethod")
.getExceptionTypes();
assertFalse(asList(declaredExceptions).contains(IOException.class));
}
@SneakyThrows
public void myMethod() {
throw new IOException("simulated checked exception");
}
}⚠️ 注意事项：
- 不要尝试通过反射读取 @SneakyThrows 注解 —— 它在字节码中根本不存在；
- 若需测试私有方法（如题干中的 private create(...)），请使用 getDeclaredMethod(...) 并调用 setAccessible(true)，但仍需确保目标方法在测试前已被 Lombok 正确处理（即项目已启用 Lombok 插件且编译通过）；
- 集成测试环境（如 Maven/Gradle 构建）必须包含 Lombok 编译插件（lombok-maven-plugin 或 gradle-lombok），否则 @SneakyThrows 不生效，测试将失败；
- 对于构造函数上的 @SneakyThrows，验证逻辑类似：检查构造过程是否抛出预期异常，且构造器签名不含对应 throws。
? 总结：测试 @SneakyThrows 的本质，是测试“异常逃逸”这一编程契约是否成立。以行为驱动代替元数据断言，既符合 Lombok 的设计哲学，也更健壮、可维护。
