为了正确测试我的 Java 代码（包括意识到任何未处理的异常），我经常使用 setUncaughtExceptionHandler 作为我的工作线程，它拦截异常、发出一些噪音并调用 System.exit(1) 我注意到（在 Java 中，默认情况下，非主线程可以（！）在遇到异常时随时死亡——它们会默默地这样做，即不会关闭进程）。
我的问题是 JUnit5（带有 gradle）报告了一个以这种方式死亡的测试，因为“SKIPPED”又名 Ignored，而不是失败。令我惊讶的是，测试套件报告成功。谷歌搜索“使 junit 在 System.exit 上失败”没有帮助。我错过了什么？在这种情况下如何让 JUnit 失败？
【问题讨论】：
标签： unit-testing testing junit exit
我以前看过一篇文章。它看起来不错，可能对您有帮助： https://todd.ginsberg.com/post/testing-system-exit/
首先，我非常同意这个想法：
编写一个在被测时实际退出JVM的单元测试绝对不理想。
为了避免这篇文章有一天失效，我先引用部分内容：
每当 JVM 做了一些有趣的事情（比如退出或读取文件）时，它首先检查它是否有权限这样做。这是通过咨询系统正在使用的 SecurityManager 来完成的。 SecurityManager 上的方法之一是 checkExit()。如果该方法抛出 SecurityException，则表示此时不允许系统退出。方便的是， checkExit() 接受一个参数 - 正在尝试的退出状态代码。
现在我们知道了，我们可以制定一个行动计划：
- 编写一个始终阻止 System.exit() 的 SecurityManager，并记录尝试的代码。
- 对我们的 SecurityManager 的任何其他调用都应委托给在我们的测试开始之前系统正在使用的任何 SecurityManager。
- 通过扩展模型将此与 JUnit 5 集成。
如果你需要完整的代码，请阅读那篇文章
【讨论】：
how to test System.exit 而是 how to make JUnit/Gradle fail on exits 和可选 Q 是为什么这不是默认行为。 Java 程序是否可以突然停止（甚至退出代码非零）并且被最流行的 Java 测试框架认为是可以的，这是真的吗？？