先介绍下这篇博文的由来，之前已经对JUnit的使用经行了深入的介绍和演示(参考JUnit学习（一），JUnit学习（二）)，其中的部分功能是通过分析JUnit源代码找到的。得益于这个过程有幸完整的拜读了JUnit的源码十分赞叹作者代码的精美，一直计划着把源码的分析也写出来。突发奇想决定从设计模式入手赏析JUnit的流程和模式的应用，希望由此能写出一篇耐读好看的文章。于是又花了些时日重读《设计模式》以期能够顺畅的把两者结合在一起，由于个人水平有限难免出现错误、疏漏，还请各位高手多多指出、讨论。
图一 TestCase运行时序图
首先，介绍下JUnit的测试用例运行会经过哪些过程，这里说起来有些抽象会让人比较迷惑，在看了后面章节的内容之后就比较清晰了：
Client（JUnitCore、Eclipse）：这里是TestCase开始的地方，如果是Main函数来启动测试用例的话一般会调用JUnitCore的方法，如果是在Eclipse中使用JUnit插件则实际上调用的是org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference这个类。 Request（org.junit.runner.Request）：Client会根据测试类或方法而创建一个Request实体，Request包含了要被执行的测试类、测试方法等信息。 RunnerBuilder：在创建后Client调用Request.getRunner()方法获取用于执行测试的Runner，该过程是由RunnerBuilder这个工厂类完成的。 RunNotifier：在执行Runner.run方法时Client还会传递一个RunNotifier对象，是事件的监听器的管理员。Runner在开始执行、成功、失败和执行结束时会调用RunNotifier中相应的方法从而发送事件给注册了的监听器，JUnit运行的最终结果就是这些监听器收集展现的。 Runner：从名字可以猜出这里应该是测试用例运行的地方了，在Client调用了Runner.run()方法之后，Runner会先构造Statement对象将所有要执行的逻辑委托给它，接着执行Statement.evaluate()方法。在这期间Runner会触发RunNotifier（如测试开始、测试结束等等）。 Statement：测试用例的运行时描述，关注于测试用例如何运行和调用测试代码。比如在执行测试用例前是否有@Before注释的方法需要调用等信息都会被Runner构造为Statement。
图二 JUnit的类结构
首先先介绍下JUnit中的模型类（Model），在JUnit模型类可以划分为三个范围：
描述模型：是对要执行的测试用例的描述（比如要执行哪个类的哪个方法，是否有指定Runner，使用了哪些注解等），这一层类似于流程文件之于流程引擎——不是用来执行的，而是描述要有哪些环节、细节。个人认为这一模型包括测试类本身（即你自己编写的测试用例）和Request。其中测试类本身等同于描述文件，Request则记录了是要运行的Suit、测试类或者是某个具体的方法、过滤器、排序的Comparator等信息（JUnit是支持对测试方法排序和过滤的）。运行时模型：是JUnit中可执行的模型，包括FrameworkMember（org.junit.runners.model.FrameworkMember）及其子类、TestClass（org.junit.runners.model.TestClass）、Statement。FrameworkMember的子类包括FrameworkMethod和FrameworkField分别描述了测试类的方法和变量信息，比如是否为静态、作用域、包含哪些注解等JUnit运行时需要用到的信息；TestClass的作用有些类似FrameworkMember，是针对测试的Class的描述。Statement在上面已经介绍过是对测试执行流程和细节的描述。结果模型：JUnit中用于描述用例的类，包括Description（org.junit.runner.Description）、Result（org.junit.runner.Result）、Failure（org.junit.runner.notification.Failure）。Description是对测试用例的描述（测试名称、所在Class的名字、是否是suit等等）只为RunNotifier提供服务。Result是运行结果的描述，用例执行完成后RunNotifier的 fireTestRunFinished(final Result result)方法会被触发，传入的Result实例描述了运行耗时、忽略的用例次数、是否成功等信息。Failure则是用例失败后Runner传递给RunNotifier的对象用于描述错误信息，特别包含了错误的StackTrace。 言归正传，下面讨论设计模式和JUnit的源码：
工厂方法模式、职责链：用例启动，Client在创建Request后会调用RunnerBuilder（工厂方法的抽象类）来创建Runner，默认的实现是AllDefaultPosibilitiesBuilder，根据不同的测试类定义（@RunWith的信息）返回Runner。AllDefaultPosibilitiesBuilder使用职责链模式来创建Runner，部分代码如下。代码A是AllDefaultPosibilitiesBuilder的主要构造逻辑构造了一个【IgnoreBuilder->AnnotatedBuilder->SuitMethodBuilder->JUnit3Builder->JUnit4Builder】的职责链，构造Runner的过程中有且只有一个handler会响应请求。代码B是Junit4Builder类实现会返回一个BlockJUnit4ClassRunner对象，这个是JUnit4的默认Runner。public Runner runnerForClass(Class<?> testClass) throws Throwable { List<RunnerBuilder> builders = Arrays.asList( ignoredBuilder(), annotatedBuilder(), suiteMethodBuilder(), junit3Builder(), junit4Builder()); for (RunnerBuilder each : builders) { Runner runner = each.safeRunnerForClass(testClass); if (runner != null) { return runner; } } return null; }代码A 职责链实现
public class JUnit4Builder extends RunnerBuilder { @Override public Runner runnerForClass(Class<?> testClass) throws Throwable { return new BlockJUnit4ClassRunner(testClass); }}代码B JUnit4Builder实现
组合模式：将具备树形结构的数据抽象出公共的接口，在遍历的过程中应用同样的处理方式。这个模式在Runner中的应用不是很明显，扣进来略有牵强。Runner是分层次的，父层包括@BeforeClass、@AfterClass、@ClassRule注解修饰的方法或变量，它们在测试执行前或执行后执行一次。儿子层是@Before、@After、@Rule修饰的方法或变量它们在每个测试方法执行前后执行。当编写的用例使用Suit来运行时则是三层结构，上面的父子结构中间插入了一层childrenRunners，也就是一个Suilt中每个测试类都会生成一个Runner，调用顺序变成了Runner.run()>childRunner.run()<即遍历childrenRunners>->testMethod()。ParentRunner中将变化的部分封装为runChild()方法交给子类实现，达到了遍历过程使用同样处理方式的目的——ParentRunner.this.runChild(each,notifier)。public void run(final RunNotifier notifier) { EachTestNotifier testNotifier = new EachTestNotifier(notifier, getDescription()); try { Statement statement = classBlock(notifier); statement.evaluate(); } catch (AssumptionViolatedException e) { testNotifier.fireTestIgnored(); } catch (StoppedByUserException e) { throw e; } catch (Throwable e) { testNotifier.addFailure(e); } } PRivate void runChildren(final RunNotifier notifier) { for (final T each : getFilteredChildren()) { fScheduler.schedule(new Runnable() { public void run() { ParentRunner.this.runChild(each, notifier); } }); } fScheduler.finished(); }代码C ParentRunner的组合模式应用
模板方法模式：模板方法的目的是抽取公共部分封装变化，在父类中会包含公共流程的代码，将变化的部分封装为抽象方法由子类实现（就像模板一样框架式定好的，你去填写你需要的内容就行了）。JUnit的默认Runner——BlockJUnit4ClassRunner继承自ParentRunner，ParentRunner类定义了Statement的构造和执行流程，而如何执行儿子层的runChild方法时交给子类实现的，在BlockJUnit4ClassRunner中就是去构造和运行TestMethod，而另一个子类Suit中则是执行子层次的runner.run。
图三 RunNotifier的公共方法
代码D RunNotifier代码截取
装饰模式：保持对象原有的接口不改变而透明的增加对象的行为，看起来像是在原有对象外面包装了一层（或多层）行为——虽然对象还是原来的类型但是行为逐渐丰富起来。 之前一直在强调Statement描述了测试类的执行细节，到底是如何描述的呢？代码E展示了Statement的构筑过程，首先是调用childrenInvoker方法构建了Statement的基本行为——执行所有的子测试runChildren(notifier)（非Suit情况下就是TestMethod了，如果是Suit的话则是childrenRunners）。接着是装饰模式的应用，代码F是withBeforeClasses()的实现——很简单，检查是否使用了@BeforeClasses注解修饰如果存在构造RunBefores对象——RunBefore继承自Statement。代码H中的evaluate()方法可以发现新生成的Statement在执行runChildren（fNext.evaluate()）之前遍历所有使用@BeforeClasses注解修饰的方法并执行。产生的效果即使用@BeforeClasses修饰的方法会在所有用例运行前执行且只执行一次。后面的withAfterClasses、withClassRules方法原理一样都使用了装饰模式，不再赘述。protected Statement classBlock(final RunNotifier notifier) { Statement statement = childrenInvoker(notifier); statement = withBeforeClasses(statement); statement = withAfterClasses(statement); statement = withClassRules(statement); return statement; } protected Statement childrenInvoker(final RunNotifier notifier) { return new Statement() { @Override public void evaluate() { runChildren(notifier); } }; }代码E Statement的构造
protected Statement withBeforeClasses(Statement statement) { List<FrameworkMethod> befores = fTestClass .getAnnotatedMethods(BeforeClass.class); return befores.isEmpty() ? statement : new RunBefores(statement, befores, null); }代码F withBeforeClasses实现
public class RunBefores extends Statement { private final Statement fNext; private final Object fTarget; private final List<FrameworkMethod> fBefores; public RunBefores(Statement next, List<FrameworkMethod> befores, Object target) { fNext = next; fBefores = befores; fTarget = target; } @Override public void evaluate() throws Throwable { for (FrameworkMethod before : fBefores) { before.invokeExplosively(fTarget); } fNext.evaluate(); }}代码H RunBefores实现
策略模式：针对相同的行为在不同场景下算法不同的情况，抽象出接口类，在子类中实现不同的算法并提供算法执行必须Context信息。JUnit中提供了Timeout、ExpectedException、ExternalResource等一系列的TestRule用于丰富测试用例的行为，这些TestRule的都是通过修饰Statement实现的。修饰Statement的代码在withRules()方法中实现，使用了策略模式。代码I描述了JUnit是如何处理@Rule标签的，withRules方法获取到测试类中所有的@Rule修饰的变量，分别调用withMethodRules和withTestRules方法，前者是为了兼容JUnit3版本的Rule这里忽略，后者withTestRules的逻辑很简单首先查看是否使用了@Rule，如存在就交给RunRules类处理。代码J是RunRules的实现，在构造函数中处理了修饰Statement的逻辑（applyAll方法）——抽象接口是TestRule，根据不同的场景（即使用@Rule修饰的不同的TestRule的实现）选择不同的策略（TestRule的具体实现），而Context信息就是入参（result:Statement, description:Description）。private Statement withRules(FrameworkMethod method, Object target, Statement statement) { List<TestRule> testRules = getTestRules(target); Statement result = statement; result = withMethodRules(method, testRules, target, result); result = withTestRules(method, testRules, result); return result; }private Statement withTestRules(FrameworkMethod method, List<TestRule> testRules, Statement statement) { return testRules.isEmpty() ? statement : new RunRules(statement, testRules, describeChild(method)); }代码I rule的执行
public class RunRules extends Statement { private final Statement statement; public RunRules(Statement base, Iterable<TestRule> rules, Description description) { statement = applyAll(base, rules, description); } @Override public void evaluate() throws Throwable { statement.evaluate(); } private static Statement applyAll(Statement result, Iterable<TestRule> rules, Description description) { for (TestRule each : rules) { result = each.apply(result, description); } return result; }}代码J RunRules实现
这里简单举一个Timeout的代码。Timeout首先实现了TestRule方法并在apply中定义了自己的算法——构造一个FailOnTimeout对象并返回。不再详细描述FailOnTimeout的实现，主要原理就是起一个线程来跑测试代码并等待线程指定的时间，如果超时就会抛出异常。public class Timeout implements TestRule { private final int fMillis; /** * @param millis the millisecond timeout */ public Timeout(int millis) { fMillis = millis; } public Statement apply(Statement base, Description description) { return new FailOnTimeout(base, fMillis); }}代码K Timeout实现
外观模式：封装统一的对外接口，隐藏内部各个小模块之间的调用细节，使得用户既可以简单的使用facade来达到目的，必要时又可以自行操作内部对象。这里的举例可能不是非常明显。图四是TestClass的公共方法，代码L给出了 TestClass(org.junit.runners.model.TestClass)的一小部分代码，TestClass主要作用是封装对Class的操作提供了JUnit运行时需要用到的功能并隐藏其中操作的细节。在TestClass内部将功能委托给了三个对象Class（java.lang.Class）、FrameworkMethod、FrameworkField来实现，本身充当了外观（facade）对外提供了getName、getOnlyConstructor、getAnnotations等等接口，在必要的时又可以通过这个外观获取到Class、FrameworkMethod等对象。
图四 TestClass的公共方法
public class TestClass { private final Class<?> fClass; private Map<Class<?>, List<FrameworkMethod>> fMethodsForAnnotations = new HashMap<Class<?>, List<FrameworkMethod>>(); private Map<Class<?>, List<FrameworkField>> fFieldsForAnnotations = new HashMap<Class<?>, List<FrameworkField>>(); /** * Creates a {@code TestClass} wrapping {@code klass}. Each time this * constructor executes, the class is scanned for annotations, which can be * an expensive process (we hope in future JDK's it will not be.) Therefore, * try to share instances of {@code TestClass} where possible. */ public TestClass(Class<?> klass) { fClass = klass; if (klass != null && klass.getConstructors().length > 1) { throw new IllegalArgumentException( "Test class can only have one constructor"); } for (Class<?> eachClass : getSuperClasses(fClass)) { for (Method eachMethod : MethodSorter.getDeclaredMethods(eachClass)) { addToAnnotationLists(new FrameworkMethod(eachMethod), fMethodsForAnnotations); } for (Field eachField : eachClass.getDeclaredFields()) { addToAnnotationLists(new FrameworkField(eachField), fFieldsForAnnotations); } } } ……}代码L TestClass截取
转自：junit源码与设计模式欣赏
新闻热点
疑难解答
