简而言之：JRunner

关于JUnit测试要点的多篇教程的第四章介绍了该工具可交换测试运行器体系结构的目的，并介绍了一些可用的实现。 正在进行的示例通过编写参数化测试的不同可能性扩大了主题。

由于我已经发布了JUnit Rules的介绍，因此我决定跳过关于该主题的已宣布部分。 相反，我对后者进行了较小的更新。

测试跑步者架构

不要害怕为了伟大而放弃美好。
约翰·洛克菲勒

在先前的文章中，我们学习了将某些xUnit测试模式[MES]与JUnit一起使用。 工具运行时的默认行为很好地支持了这些概念。 但是有时需要针对特定​​的测试类型或目标更改或补充后者。

考虑例如集成测试 ，该测试通常需要在特定环境中运行。 或想象一组包含子系统规范的测试用例，应该为常见的测试执行而组成。

为此，JUnit支持使用各种类型的测试处理器。 因此，它在运行时将测试类实例化，测试执行和结果报告委托给此类处理器，这些处理器必须是org.junit.Runner子类型。

测试用例可以使用@RunWith注释指定其预期的运行器类型。 如果未指定任何类型，那么运行时将选择BlockJUnit4ClassRunner作为默认值。 负责每个测试运行一个新的测试实例，并调用诸如隐式设置或拆卸处理程序之类的生命周期方法（另请参见有关测试结构的章节）。

@RunWith( FooRunner.class )
public class BarTest {
   

该代码段显示了如何将虚构的FooRunner指定为也是虚构的BarTest测试处理器。

通常，无需编写自定义测试运行程序。 但是，如果需要的话， Michael Scharhag最近就对JUnit的运行器体系结构进行了很好的解释。

看起来特殊测试运行程序的用法很简单，所以让我们看一下其中的几个：

套房和类别