我创建了一个单元测试框架 pFUnit，它在很大程度上遵循了 JUnit 的当前设计，并且正在寻找有关如何扩展该框架以处理特定情况的建议。出于好奇，这个框架 pFUnit 是用 OO Fortran 编写的（是的——Fortran 现在具有 OO 功能！）并支持使用 MPI 进行分布式编程。但我认为关于语言选择的唯一相关方面是，如果 SUT 真的崩溃了，那么测试框架也会崩溃。幸运的是，这是一种相对罕见的情况，但它仍然经常发生，足以让人们尖叫着寻求解决方案。
我的意图是提供一个替代的 TestRunner，它将每个测试作为一个单独的可执行文件作为 RPC 或类似的东西运行。这样做的运行时开销可能很大，尤其是在重复启动 MPI 时，所以我不想让它成为默认行为。不幸的是，当我研究如何编写这种方法时，我发现 TestRunner 似乎并不适合这样的扩展，因为它只管理嵌套的 TestSuite 系列的顶部的运行。
通过让 TestRunner 导航嵌套结构，我可以看到一种使其工作的笨拙方式，但这会在很大程度上破坏 TestSuite 的作用。
实际上，我想出的最简单的方法是继承 TestResult。TestResult 在每个 TestCase 上调用 runBare()，因此扩展可能只是启动一个单独的可执行文件，该可执行文件只调用该 runBare() 方法并返回任何异常。这个解决方案打扰了我的审美，因为它不是 TestResult 应该负责的事情。
我还可以向 TestCase 添加一个 launch() 方法，该方法检查一些全局参数以确定是作为过程运行还是作为单独的可执行文件启动。这看起来不优雅，但可能并不比我之前提到的 TestResult 扩展难多少。
希望这是足够的背景知识，对 JUnit 的设计有更深入了解的人可以提出比我提出的替代方案更好/更清洁的方法。或者如果失败，可以为我提出的设计罪提供宽恕。