用 assertthrows 断言 illegalargumentexception，传入 lambda 表达式如 () -> parsenumber("abc")，返回异常实例可链式校验消息；比 try-catch 更可靠，因它确保异常发生且类型匹配，未抛出时立即报错。
JUnit 5 怎么断言某个方法真的抛出了 IllegalArgumentException
直接用 assertThrows，别写 try-catch 手动验证。它返回被抛出的异常对象，方便后续检查消息或类型。
常见错误是只调用方法却不捕获异常，导致测试直接失败；或者用了旧版 JUnit 4 的 @Test(expected = ...)，在 JUnit 5 中不生效且无法校验异常细节。
-
assertThrows必须传入一个Executable（通常是 lambda），不能直接传方法调用表达式 - 如果被测方法有参数，确保 lambda 内完整调用，比如
() -> parseNumber("abc")，不是parseNumber("abc") - 返回值是异常实例，可以链式调用
getMessage()或getCause()做进一步断言
Exception ex = assertThrows<IllegalArgumentException>(() -> parseNumber("xyz"));
assertEquals("Invalid number format", ex.getMessage());
为什么 assertThrows 比 try-catch 更可靠
手动 try-catch 容易漏掉“没抛异常”的情况：catch 块空着、忘记写 fail()、或者把异常吞掉后没处理，测试会误通过。
assertThrows 内部做了两件事：确保异常确实发生，且类型匹配；一旦没抛出，立刻报错并提示“Expected exception of type … but no exception was thrown”。
立即学习“Java免费学习笔记（深入）”；
- 兼容性上，
assertThrows是 JUnit Jupiter（JUnit 5）核心 API，JDK 8+ 可用，无需额外依赖 - 性能无差异，底层就是封装了 try-catch + 类型检查，但语义更清晰
- 不支持检查异常的嵌套结构（比如
getCause().getCause()），得靠返回的异常对象手动展开
测试受检异常（checked exception）要注意什么
Java 编译器会强制你处理受检异常，但在 lambda 里直接 throw 会导致编译错误，因为 Executable 接口不声明抛出任何异常。
解决办法不是改接口，而是让被测代码在测试上下文中“绕过”编译检查——最稳妥的方式是把调用包装进一个不抛受检异常的 lambda，由你来显式转换。
- 不要用
throws Exception声明 lambda，Java 不允许 - 可以在 lambda 里用 try-catch 把受检异常转成运行时异常，再抛出（
throw new RuntimeException(e)） - 更干净的做法是：确保被测方法在测试场景下确实会走抛出受检异常的分支，且该异常在 lambda 中能被
assertThrows捕获到（JVM 层面它仍是那个异常）
// 正确：即使 IOException 是 checked，assertThrows 仍能捕获
IOException ex = assertThrows<IOException>(() -> {
try {
Files.readString(Paths.get("missing.txt"));
} catch (IOException e) {
throw new RuntimeException(e); // 包装后抛出
}
});
断言异常时容易忽略的边界情况
异常消息含空格、换行、本地化文本，直接用 assertEquals 易失败；还有并发场景下异常可能偶发、日志干扰输出、或者多个异常类型都可能抛出但只断言了其中一个。
- 消息比对优先用
assertTrue(ex.getMessage().contains("timeout"))，而非全等 - 若方法可能抛多种异常（如
IOException或SecurityException），先用assertThrows指定最具体的类型，再补充逻辑分支测试 - 避免在
assertThrows的 lambda 里做副作用操作（如修改共享状态），否则异常未抛出时副作用仍会发生
异常断言看着简单，真正难的是覆盖所有触发路径、不依赖环境副作用、并且消息校验不过于脆弱。写完多看一眼堆栈是不是真来自被测方法，而不是某层工具类。
