我已经创建了一个单元测试框架pFUnit，它主要遵循当前的JUnit设计，并且正在寻找有关如何扩展此框架以处理某种情况的建议。好奇的是，这个框架pFUnit是用OO Fortran编写的（是的 - Fortran现在具有OO功能！）并支持使用MPI进行分布式编程。但我认为语言选择的唯一相关方面是，如果SUT实际崩溃，测试框架也会这样做。幸运的是，这是一种相对罕见的情况，但它仍然经常发生，以便为解决方案而尖叫。
我的目的是提供一个备用的TestRunner，它将每个测试作为RPC或类似的单独可执行文件运行。此操作的运行时开销可能很大，尤其是在重复启动MPI时，因此我不想将此作为默认行为。不幸的是，当我研究如何编写这种方法时，我发现TestRunner似乎并不适合这样的扩展，因为它只管理嵌套的TestSuite seriest顶部的运行。
通过让TestRunner导航嵌套结构，我可以看到一种使其工作的笨重方式，但它会以一种主要方式破坏TestSuite的作用。
实际上，我提出的最简单的方法是继承TestResult。 TestResult在每个TestCase上调用runBare（），因此扩展可能只是启动一个单独的可执行文件，它只调用runBare（）方法并返回任何异常。这个解决方案困扰着我的美学意识，因为它不是TestResult应该负责的事情。
我还可以向TestCase添加一个launch（）方法，该方法检查一些全局参数，以确定是作为过程运行还是作为单独的可执行文件启动。这似乎不够优雅，但可能并不比我之前提到的TestResult扩展困难得多。
希望这是足够的背景，一个对JUnit设计有更深入了解的人可以提出比我提出的替代方案更好/更清洁的方法。或者说失败让我对我提出的设计罪行感到赦免。
答案 0 :(得分：0)
JUnit不会这样做，它会将其留给调用JUnit的东西，例如Eclipse或Maven surefire。
Eclipse分叉jvm，然后在单独的JVM中执行，并通过与分叉JVM的连接传递结果。
Maven surefire有一些选项，用户可以控制分叉的方式和时间 - 它有不同的分叉选项，请参阅Maven Surefire - Fork Options and Parallel Test Execution。
一个选项是拥有一个ForkingTestRunner，一个分叉的TestRunner。然后你可以做相当于@RunWith(ForkingTestRunner.class)的每个测试方法分配一次。
如果这仍然太慢，您可以派一个跑步者，并通过套接字或其他东西将结果传回监控进程。如果SUT崩溃，则监视器进程检测到此情况并且未通过测试并重新启动运行程序（但具有减少的列表）。
这样你每组测试只有一个分叉，除非SUT崩溃了。