Gradle test默认不输出完整堆栈是因JUnit报告机制设计取舍，需用--stacktrace、配置junit.jupiter.stacktrace.mode=always及testLogging exceptionFormat='full'三者结合才能在控制台显示断言位置、参数值和深层异常。
测试失败时只看到 java.lang.AssertionError 或一行摘要，根本看不出哪行断言炸了、参数值是多少、深层异常被吞没——这说明 Gradle 默认压制了完整堆栈，必须手动打开。
test任务默认不输出完整堆栈的原因
Gradle 的 test 任务默认使用 JUnit 的标准报告机制，失败时只把简短消息（如 expected but was ）写进控制台，而真实异常的完整调用链（包括 Caused by 嵌套、源码行号）被收进 XML 报告或直接丢弃。这不是 bug，是设计取舍：避免刷屏，但调试时极不友好。
加 --stacktrace 让 test 输出完整堆栈
最直接的办法是强制 Gradle 显示执行过程中的 JVM 异常堆栈：
-
./gradlew test --stacktrace→ 输出从测试框架抛出点开始的完整堆栈，含所有Caused by层级 -
./gradlew test --full-stacktrace→ 还会包含 Gradle 内部调用链（一般没必要，Groovy 动态代理层堆栈干扰判断） - 注意：这个参数影响的是 Gradle 自身任务执行的异常，不是测试用例里
catch后再抛的包装异常——后者得靠日志或断点
让 JUnit 本身在控制台打印详细失败信息
仅靠 --stacktrace 不够，JUnit 5 默认仍会截断深层原因。需在 build.gradle 中配置测试 JVM 参数：
test {
jvmArgs = ['-Djunit.jupiter.stacktrace.mode=always']
}
这样每个失败的 @Test 方法都会在控制台打出完整堆栈，包括：
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 断言失败的具体位置（类、方法、行号）
- 实际值与期望值的完整 toString() 输出（对集合、对象更友好）
- 如果用了
assertThrows并嵌套了异常，Caused by也会展开
捕获测试中未处理的异常并转成可读日志
有些测试失败是因为代码抛了未捕获的 RuntimeException（比如空指针），JUnit 只报“test failed”，不显堆栈。这时可在 test 任务里加一个失败监听器：
test {
testLogging {
exceptionFormat = 'full'
events = ['failed', 'standardError', 'standardOut']
}
}
关键点：
-
exceptionFormat = 'full'强制 JUnit 将失败异常以完整格式输出到控制台 -
events = ['failed']就够了，加standardError是为了防某些库把堆栈打到 stderr 而被忽略 - 这个配置不影响 XML 报告内容，只改控制台输出
真正容易被忽略的是：当测试里手动 catch 了异常又重新 throw new RuntimeException("wrapper", e) 时，JVM 堆栈已被重置，原始行号丢失。这种情况下，光靠 --stacktrace 没用，得在 catch 块里主动记录 e.printStackTrace() 或用 logger.error("", e) ——否则你永远看不到第一现场。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
