前面我整理了junit38系列的源码,那junit4X核心代码也基本类似。这里我先转载一些关于junit4X源码解析的好文章。感谢原作者的分享。原文地址:http://www.blogjava.net/DLevin/archive/2012/05/11/377950.html。

初次用文字的方式记录读源码的过程,不知道怎么写,感觉有点贴代码的嫌疑。不过中间还是加入了一些自己的理解和心得,希望以后能够慢慢的改进,感兴趣的童鞋凑合着看吧,感觉JUnit这个框架还是值得看的,里面有许多不错的设计思想在,更何况它是Kent
Beck和Erich Gamma这样的大师写的。。。。。



写在前面的话

不知道是因为第一份工作的影响还是受在博客园上看到的那句“源代码里没有秘密”的影响,总之,近来对很多框架的源码都很感兴趣,拿到一个都想看看。其实自从学习Java以来也看过不少了,从刚开始接触的Tomcat,到Struts2,再到入职当前这份工作后看的Log4J,Commons Validator和SpringBatch,可惜除了Commons Validator的源码都看完了,其他的框架源码都半途而废了,并且Commons Validator看完后,也没有什么记录下来,所以基本上都可以忽略,其实当时也知道看完要有总结和记录才会有真正的收获,然而还是因为各种事情而没有做。所以这次看JUnit,发奋看完后一定要做总结,并记录。

对于JUnit,一直以为很简单,可以很快的看完,就当练练手,然而当我真正看完后,才发现JUnit其实并不简单,内部框架提供了很多特性,平时都没用过,而且也没见过,比如使用RunWith注解以指定特定的Runner、Rule、使用hamcrest框架的Assert.assertThat()方法等。其实JUnit提供的这些特性在一些特殊场合很有用处,然而对于单元测试,很多人却因为太忙或者因为嫌烦,维护麻烦等各种理由而尽量避免。我也是一样,虽然我一直承认单元测试非常重要,它不仅仅可以在前期影响设计、而且可以为后期的一些重构或者bug修复提供信心,但是要我真正的认真的为一个模块写单元测试,也感觉有点厌烦,再加上当前项目又是一个很少写单元测试的环境,对这方面坚持就松懈了。

后来,想系统的看一下项目的源码,可是代码量太多,也没有比较明确的模块分工,没有比较完善的单元测试,再加上当前项目主要是基于文件对数据的处理,没有看到数据流,只是看代码的话,感觉晕头转向的,所以就想着补一些单元测试以使自己可以更好的理解项目代码。问题是项目是跑在Linux Server上的,项目在开发的过程中没有完全考虑支持跨平台,同时有些操作内存消耗也很大,所以并不是所有的代码都可以在本地跑,等等,总之各种原因吧,我开始打算写一个可以在Linux下用跑测试代码的工具。然后悲剧的发现除了会使用eclipse中的JUnit,其实我对JUnit一无所知。所以有些时候工具虽然能提供我们方便,但是它也隐藏了内部细节,最后我们自以为已经很了解某些东西了,其实离开了工具,我们一无所知。

最后加个注释,这篇文章所有的代码是基于JUnit4.10的,今天我发现这个版本和之前的版本(JUnit4.4)的代码还是有比较大的差别的。本系列最后可能会涉及到一点和JUnit之前版本相关的信息,不过这个就要看有没有这个时间了。L

深入JUnit源码之Runner

Runner是JUnit的核心,它封装了一个测试类中所有的测试方法,如BlockJUnit4ClassRunner,或者是多个Runner,如Suite;在运行过程中,遍历并运行所有测试方法(可以通过Filter和Sorter控制是否要执行某些测试方法以及执行测试方法的顺序)。

在使用JUnit时,可能最常用的几个注解就是@BeforeClass、@AfterClass、@Before、@After、@Test、@Ignore了,这几个注解所表达的意思相信很多人都很熟悉了,并且从它们的名字中也可以略知一二。这几个注解,除了@Test标记了哪个方法为测试方法,该方法必须为public,无返回,不带参;@Ignore标明某个方法即使有@Test的注解,也会忽略不运行,如JUnit文档中解释,在某些情况下,我们可能想临时的不想执行某些测试方法,除了将该测试方法整个注释掉,JUnit为我们提供了@Ignore注解,此时即使某方法包含@Test注解,该方法也不会作为测试方法执行,@Ignore还可以注解在类上,当一个类存在@Ignore注解时,该类所有的方法都不会被认为是测试方法;而剩下的四个注解则是JUnit为在测试类运行时的不同切面提供了切入点,如@BeforeClass和@AfterClass注解分别在测试类运行时前后各提供了一个切入点,这两个注解必须使用在public,静态,无返回,不带参的方法中,可以为每种注解指定多个方法,多个方法的执行顺序依赖与Java的反射机制,因而对一种注解的多个方法,在实际中不应该存在顺序依赖,为一种注解写多个方法的情况应该很少;而@Before和@After注解则是在每个测试方法的运行前后各提供了一个切入点,这两个注解必须使用在public,无返回,不带参的方法中。同@BeforeClass和@AfterClass,同一种注解可以注释多个方法,他们的执行顺序也依赖于反射机制,因而不能对顺序有依赖。更直观的,如下图所示。

加点不完全相关的,这事实上是一种AOP思想的实现。自从知道AOP后,一直很喜欢这个想法,它事实上也是一种分层的思想。一个request从一个管道流进,经过层层处理后从另一个管道流出,在管道的流动过程中,每一层都对自己实现的功能做一些处理,如安全验证、运行时间记录、进入管道后打开某个链接出去之前关闭该链接、异常记录等等相对独立的功能都可以抽取出来到一个层中,从而在实际编码业务逻辑过程中可以专注于业务,而不用管这些不怎么相关但有必须有的逻辑,不仅是代码的模块分层更加清晰,减轻程序员的负担,还提高了程序的安全性,因为这样就可以部分避免有些事情必须要做容易忘了尴尬。AOP的思想最出名的应该是Spring中提供的支持了,但是我个人更喜欢Struts2通过Interceptor提供的AOP实现,这是题外话。

一个简单的测试例子

为了更加清晰的了解JUnit的一些行为,我们先来看一下如下的一个测试例子:

 1 public class CoreJUnit4SampleTest {

 2     @BeforeClass

 3     public static void beforeClass() {

 4         System.out.println("beforeClass() method executed.");

 5         System.out.println();

 6     }

 7     @BeforeClass

 8     public static void beforeClass2() {

 9         System.out.println("beforeClass2() method executed.");

         System.out.println();

     }

     @AfterClass

     public static void afterClass() {

         System.out.println("afterClass() method executed.");

         System.out.println();

     }

     @Before

     public void before() {

         System.out.println("before() method executed.");

     }

     @After

     public void after() {

         System.out.println("after() method executed");

     }

     @Test

     public void testSucceeded() {

         System.out.println("testSucceeded() method executed.");

     }

     @Test

     @Ignore

     public void testIgnore() {

         System.out.println("testIgnore() method executed.");

     }

     @Test

     public void testFailed() {

         System.out.println("testFailed() method executed.");

         throw new RuntimeException("Throw delibrately");

     }

     @Test

     public void testAssumptionFailed() {

         System.out.println("testAssumptionFailed() method executed.");

 ));

     }

     @Test

     public void testFilteredOut() {

         System.out.println("testFilteredOut() method executed.");

     }

 }

这个是一个简单的测试类,内部实现基本上只是打印,以确定测试方法的运行位置。该测试方法包括两个@BeforeClass注解的方法,以测试多个@BeforeClass注解时他们的运行顺序问题;@AfterClass、@Before、@After注解的方法各一个,以测试他们的运行位置问题;在多个@Test注解的测试方法中,testSucceeded()测试方法用于测试通过时RunLinstener的运行结果,testIgnore()测试方法测试@Ignore注解对测试结果的影响,testFailed()方法测试在测试方法抛异常时RunListener的运行结果,testAssumptionFailed()方法测试在测试方法断言出错时RunListener的运行结果,testFilteredOut()方法测试Filter的功能。在JUnit中,BlockJUnitClassRunner是其最核心的Runner,它对一个只包含测试方法的测试类的运行做了封装,并且它还实现了Filterable和Sortable的接口,因而支持Filter和Sorter,为了更全面的展现JUnit提供的功能,我在这个例子中还加入了Filter和Sorter的测试,其中实现了一个Filter类:MethodNameFilter,在构造时指定要过滤掉的方法名,Runner在运行之前调用filter()方法,以过滤掉这些方法。对于Sorter只实现了一个按字母序排列的Comparator,它会以参数形式传递给Sorter构造函数,以决定测试方法的顺序,Runner在运行之前调用sort()方法,以按指定的顺序排列测试方法:

 1 public class MethodNameFilter extends Filter {

 2     private final Set<String> excludedMethods = new HashSet<String>();

 3     public MethodNameFilter(String excludedMethods) {

 4         for(String method : excludedMethods) {

 5             this.excludedMethods.add(method);

 6         }

 7     }

 8     @Override

 9     public boolean shouldRun(Description description) {

         String methodName = description.getMethodName();

         if(excludedMethods.contains(methodName)) {

             return false;

         }

         return true;

     }

     @Override

     public String describe() {

         return this.getClass().getSimpleName() + "-excluded methods: " + 

                 excludedMethods;

     }

 }

 public class AlphabetComparator implements Comparator<Description> {

     @Override

     public int compare(Description desc1, Description desc2) {

         return desc1.getMethodName().compareTo(desc2.getMethodName());

     }

 }

由于本文主要讲解JUnit中的Runner的实现,因而在这个例子中,我将直接构造BlockJUnit4ClassRunner实例,以运行上述的测试类:

 1 public class BlockJUnit4ClassRunnerExecutor {

 2     public static void main(String[] args) {

 3         RunNotifier notifier = new RunNotifier();            

 4         Result result = new Result();

 5         notifier.addFirstListener(result.createListener());

 6         notifier.addListener(new LogRunListener());

 7         

 8         Runner runner = null;

 9         try {

10             runner = new BlockJUnit4ClassRunner(CoreJUnit4SampleTest.class);

11             try {

12                 ((BlockJUnit4ClassRunner)runner).filter(new MethodNameFilter("testFilteredOut"));

13             } catch (NoTestsRemainException e) {

14                 System.out.println("All methods are been filtered out");

15                 return;

16             }

17             ((BlockJUnit4ClassRunner)runner).sort(new Sorter(new AlphabetComparator()));

18         } catch (Throwable e) {

19             runner = new ErrorReportingRunner(CoreJUnit4SampleTest.class, e);

20         }

21         notifier.fireTestRunStarted(runner.getDescription());

22         runner.run(notifier);

23         notifier.fireTestRunFinished(result);

24     }

25 } 

JUnit会在Runner运行之前通过RunNotifier发布testRunStarted事件表示JUnit运行开始,并在Runner运行结束之后通过RunNotifier发布testRunFinished时间,表示JUnit运行结束。在Runner运行过程中,在每个测试方法开始前也会通过RunNotifier发布testStarted事件,在测试方法结束后发布testFinished事件(不管该测试方法通过还是未通过),若测试失败,则发布testFailure事件,若测试方法因调用Assume类中的方法失败(这种失败不认为是测试失败),则会发布testAssumptionFailure事件,若遇到一个Ignore测试方法,发布testIgnored事件。我们可以再RunNotifier中加入要注册的Listener(事件接收器),如上例所示,为了测试,这个例子编写的LogRunListener代码如下:

 1 public class LogRunListener extends RunListener {

 2     public void testRunStarted(Description description) throws Exception {

 4         println("==>JUnit4 started with description: \n" + description);

 5         println();

 6     }

 7     public void testRunFinished(Result result) throws Exception {

 8         println("==>JUnit4 finished with result: \n" + describe(result));

 9     }

     public void testStarted(Description description) throws Exception{

         println("==>Test method started with description: " + description);

     }

     public void testFinished(Description description) throws Exception {

         println("==>Test method finished with description: " + description);

         println();

     }

     public void testFailure(Failure failure) throws Exception {

         println("==>Test method failed with failure: " + failure);

     }

     public void testAssumptionFailure(Failure failure) {

         println("==>Test method assumption failed with failure: " + failure);

     }

     public void testIgnored(Description description) throws Exception {

         println("==>Test method ignored with description: " + description);

         println();

     }

     private String describe(Result result) {

         StringBuilder builder = new StringBuilder();

         builder.append("\tFailureCount: " + result.getFailureCount())

                .append("\n");

         builder.append("\tIgnoreCount: " + result.getIgnoreCount())

                .append("\n");

         builder.append("\tRunCount: " + result.getRunCount())

                .append("\n");;

         builder.append("\tRunTime: " + result.getRunTime())

                .append("\n");

         builder.append("\tFailures: " + result.getFailures())

                .append("\n");;

         return builder.toString();

     }    

     private void println() {

         System.out.println();

     }

     private void println(String content) {

         System.out.println(content);

     }

 }

最后这个例子的运行结果(从上面的分析中,这个运行结果应该已经很清晰了,只是有两点需要注意,其一,@Ignore注解的方法会被忽略不执行,包括@Before、@After注解的方法,也不会触发该testStarted事件,但是在Result会记录被忽略的测试方法数,而被Filter过滤掉的方法(testFilteredOut())则不会有任何记录;其二,事件的触发都是在@Before注解之前或@After注解之后,事实上,如果测试方法中包含Rule字段的话,也会在Rule执行之前或之后,这就是JUnit抽象出的Statement提供的特性,这是一个非常好的设计,这个特性将会在下一节:深入JUnit源码之Statement中讲解):

==>JUnit4 started with description: 

levin.blog.junit.sample.simple.CoreJUnit4SampleTest



beforeClass2() method executed.



beforeClass() method executed.



==>Test method started with description: testAssumptionFailed(levin.blog.junit.sample.simple.CoreJUnit4SampleTest)

before() method executed.

testAssumptionFailed() method executed.

after() method executed

>

==>Test method finished with description: testAssumptionFailed(levin.blog.junit.sample.simple.CoreJUnit4SampleTest)



==>Test method started with description: testFailed(levin.blog.junit.sample.simple.CoreJUnit4SampleTest)

before() method executed.

testFailed() method executed.

after() method executed

==>Test method failed with failure: testFailed(levin.blog.junit.sample.simple.CoreJUnit4SampleTest): Throw delibrately

==>Test method finished with description: testFailed(levin.blog.junit.sample.simple.CoreJUnit4SampleTest)



==>Test method ignored with description: testIgnore(levin.blog.junit.sample.simple.CoreJUnit4SampleTest)



==>Test method started with description: testSucceeded(levin.blog.junit.sample.simple.CoreJUnit4SampleTest)

before() method executed.

testSucceeded() method executed.

after() method executed

==>Test method finished with description: testSucceeded(levin.blog.junit.sample.simple.CoreJUnit4SampleTest)



afterClass() method executed.



==>JUnit4 finished with result: 

    FailureCount: 

    IgnoreCount: 

    RunCount: 

    RunTime: 

    Failures: [testFailed(levin.blog.junit.sample.simple.CoreJUnit4SampleTest): Throw delibrately]

深入Runner和其周边支持类的源码

从上面这个例子中,我们已经知道JUnit的核心功能以及不同注解方法执行的顺序问题,然而既然本文是关注内部源码的,因而接下来就要讨论如何实现上述的这些功能。

所谓面向对象中的类即是对某些事物或行为进行抽象和封装,从而实现某些功能,一个类可以看成是一个模块,它一般包含数据和行为,并提供给外界一定的接口,多个类之间通过各自的接口与外界交互,从而形成一个大的系统,有点类似分治的算法。在分治算法中最重要的是找到正确的方法以将问题划分成各个区间,并最后使用一定的规则将各个区间解决的问题连结在一起,以解决整个系统的问题。在面向对象中同样要找到一个正确的方法将系统的问题划分成各个小模块,用类来封装,并定义类的接口以使各个类之间可以交互连结以形成一个大的系统。在实现中,我们也经常遇到某些事物是不同的,但是他们有一些共同的属性或行为,在面向对象中对这个情况的处理是将相同的属性或行为抽象成一个父类,而由各自的子类继承父类提供各自不同的属性和行为。然而有些时候,某些事物他们都具有某种行为,但是这些行为的结果却是不同的,对这种情况,面向对象则采用多态的方式支持这种需求,即在父类中定义行为,在子类中重写行为。在面向对象设计中,如何设计系统的类结构,包括类的继承结构、类之间的交互接口等问题了是面向对象设计的核心问题。

JUnit将测试类中的方法(测试方法以及切面方法,@BeforeClass、@AfterClass、@Before、@After等注解的方法)抽象成FrameworkMethod类模块,和测试相关的字段(由@Rule和@ClassRule注解的字段)抽象成FrameworkField类模块,而这两个类具有一些共同的行为,如获取在其之上的所有注解类、是否被其他相关成员隐藏等,因而JUnit将这些共同行为提取到父类FrameworkMember中。对每个测试类,JUnit使用TestClass类来封装,TestClass类以测试类的Class实例为构造函数的参数,它收集测试类中所有JUnit识别的注解方法(@BeforeClass、@AfterClass、@Before、@After、@Test、@Ignore)和注解字段(@Rule、@ClassRule),以供其他类查询。在每一次运行中,JUnit使用Runner对其封装,它可以是只包含一个测试类的BlockJUnit4ClassRunner,也可以是包含多个Runner的Suite(这有点类似Composite设计模式,以测试方法为叶子节点,以Runner为包含叶子节点的节点将依次JUnit运行过程中的所有测试方法组成一棵树);这两个Runner都继承自ParentRunner。ParentRunner表达它是以一个在树中具有子节点的节点,实现了Filterable接口和Sortable接口,以实现filter和sort的功能,ParentRunner继承自Runner。Runner是一个更高层次的抽象,目前在JUnit4中表达该Runner只是在执行树中的没有子节点的Runner节点,如ErrorReportingRunner、IgnoredClassRunner等;在JUnit3中不是采用注解的方式取得测试方法,为了兼容性,JUnit4中也提供了JUnit38ClassRunner类以完成兼容性的工作。Runner实现了Discribable接口,以表明可以通过Description来描述一个Runner;Description主要是对Runner和测试方法的描述,有点类似toString()的味道。Runner的每一次执行过程,如切面方法的执行、测试方法的执行、Rule字段的执行等,JUnit都将其封装在Statement类中,一个测试方法的执行可能存在多个Statement,他们形成链结构,这是一个我个人非常喜欢的设计,就像Servlet中的Filter、Struts2的Interceptor的设计类似,也是对AOP的主要实现,这个内容将在另一节中介绍。Runner在每个测试方法执行过程中都会通过RunNotifier类发布一些事件,如测试方法执行开始、结束、出错、忽略等事件,RunNotifier是Runner对所有事件处理的封装,我们可以通过它注册RunListener的事件响应类,如上例的LogRunListener的注册。到这里,我们基本上已经介绍完了JUnit的所有的核心类简单的功能和一些简单的交互,那么我们来看一下他们的类结构图吧:

Description类和Discribable接口的实现

看完类结构图,那么我们再来看一下源码吧。由于Description在JUnit中应用广泛,又是相对独立于功能的,因而将从Description开始:

如上文所说,Description是JUnit中对Runner和测试方法的描述,它包含三个字段:

 private final ArrayList<Description> fChildren;

 private final String fDisplayName;    

 private final Annotation[] fAnnotations;

displayName对测试方法的格式为:<methodName>(<className>),如:

testFailed(levin.blog.junit.sample.simple.CoreJUnit4SampleTest)

对Runner来说,displayName一般为Runner所封装的测试类,然而对没有根类的Suite,该值为”null”。annotations字段为测试方法或测试类上所具有的所有注解类。children对测试方法来说为空,对Runner来说,表达Runner内部所有的测试方法的Description或Runner的Description。作为JUnit的用户,除非自定义Runner,其他的,我们一般都是通过注册自己的RunListener来实现自己想要的统计和信息提示工作,而在Listener中并没有直接暴露给我们Runner或者是测试类的实例,它是通过提供Description实例的方式来获取我们需要的信息。Description提供以下的接口供我们使用:

 1 public String getDisplayName();

 2 public ArrayList<Description> getChildren();

 3 public boolean isSuite();

 4 public boolean isTest();

 5 public int testCount();

 6 public <T extends Annotation> T getAnnotation(Class<T> annotationType);

 7 public Collection<Annotation> getAnnotations();

 8 public Class<?> getTestClass();

 9 public String getClassName();

 public String getMethodName();

Runner实现了Disacribable接口,该接口只包含一个方法:

 public interface Describable {

     public abstract Description getDescription();

 }

该方法在ParentRunner中创建一个Description,并遍历当前Runner下的Children,并将这些child的Description添加到Description中最后返回:

 1 @Override

 2 public Description getDescription() {

 3     Description description= Description.createSuiteDescription(

 4 getName(),    getRunnerAnnotations());

 5     for (T child : getFilteredChildren())

 6         description.addChild(describeChild(child));

 7     return description;

 8 }

 9 BlockJUnit4ClassRunner:

 @Override

 protected Description describeChild(FrameworkMethod method) {

     return Description.createTestDescription(

 getTestClass().getJavaClass(),

                 testName(method), method.getAnnotations());

 }

 Suite:

 @Override

 protected Description describeChild(Runner child) {

     return child.getDescription();

 }

 

RunNotifier类和RunListener类对测试方法运行事件的发布

RunListener是JUnit提供的自定义对测试运行方法统计的接口,JUnit用户可以继承RunListener类,在JUnit运行开始、结束以及每一个测试方法的运行开始、结束、测试失败以及假设出错等情况下加入一些自己的逻辑,如统计整个JUnit运行的时间(这个在Result中已经实现了)、每个运行方法的时间、运行最后有多少方法成功,多少失败等,如上例中的LogRunListener。RunListener定义了如下接口:

 1 public class RunListener {

 2     public void testRunStarted(Description description) throws Exception {

 4     }

 5     public void testRunFinished(Result result) throws Exception {

 6     }

 7     public void testStarted(Description description) throws Exception {

 8     }

 9     public void testFinished(Description description) throws Exception {

     }

     public void testFailure(Failure failure) throws Exception {

     }

     public void testAssumptionFailure(Failure failure) {

     }

     public void testIgnored(Description description) throws Exception {

     }

 }

这个类需要注意的是:1. testFinished()不管测试方法是成功还是失败,这个方法总是会被调用;2. 在测试方法中跑出AssumptionViolatedException并不认为是测试失败,一般在测试方法中调用Assume类中的方法而失败,会跑该异常,在JUnit的默认实现中,对这些方法只是简单的忽略,并发布testAssumptionFailure()事件,并不认为该方法测试失败,自定义的Runner可以改变这个行为;3. 当我们需要自己操作Runner实例是,Result的信息需要自己手动的注册Result中定义的Listener,不然Result中的信息并不会填写正确,如上例中的做法:

 Result result = new Result();

 notifier.addFirstListener(result.createListener());

在实现时,所有事件响应函数提供给我们有三种信息:Description、Result和Failure。其中Description已经在上一小节中介绍过了它所具有的信息,这里不再重复。对于Result,前段提到过只有它提供的Listener后才会取到正确的信息,它包含的信息有:总共执行的测试方法数、忽略的测试方法数、以及所有在测试过程中抛出的异常列表、整个测试过程的执行时间等,Result实例在JUnit运行结束时传入testRunFinished()事件方法中,以帮助我们做一些测试方法执行结果的统计信息,事实上,我感觉这些信息很多时候还是不够的,需要我们在自己的RunListener中自己做一些信息记录。Failure类则记录了测试方法在测试失败时抛出的异常以及该测试方法对应的Description实例,当在构建Runner过程中出现异常,Failure也会用于描述测试类,如上例中,如果beforeClass()方法不是静态的话,在初始化Runner时就会出错,此时的运行结果如下:

==>JUnit4 started with description: 

levin.blog.junit.sample.simple.CoreJUnit4SampleTest



==>Test method started with description: initializationError(levin.blog.junit.sample.simple.CoreJUnit4SampleTest)

==>Test method failed with failure: initializationError(levin.blog.junit.sample.simple.CoreJUnit4SampleTest): Method beforeClass() should be static

==>Test method finished with description: initializationError(levin.blog.junit.sample.simple.CoreJUnit4SampleTest)



==>JUnit4 finished with result: 

    FailureCount: 

    IgnoreCount: 

    RunCount: 

    RunTime: 

    Failures: [initializationError(levin.blog.junit.sample.simple.CoreJUnit4SampleTest): Method beforeClass() should be static]

Runner中的run()方法需要传入RunNotifier实例,它是对RunListener的封装,我们可以向其注册多个RunListener,当Runner需要发布某个事件时,就会通过它来代理,它则会遍历所有已注册的RunListener,并运行相应的事件。当运行某个RunListener抛异常时,它会首先将这个RunListener移除,并发布测试失败事件,在该事件中的Description为一个名为“Test
mechanism”的Description,因为此时是注册的事件处理器失败,无法获知一个Description实例:

 1 private abstract class SafeNotifier {

 2     void run() {

 3         synchronized (fListeners) {

 4             for (Iterator<RunListener> all= fListeners.iterator(); 

 5                             all.hasNext();)

 6                 try {

 7                     notifyListener(all.next());

 8                 } catch (Exception e) {

 9                     all.remove(); // Remove the offending listener first to avoid an infinite loop

                     fireTestFailure(new Failure(

                             Description.TEST_MECHANISM, e));

                 }

         }

     }

     abstract protected void notifyListener(RunListener each) throws Exception;

 }

在RunNotifier类中还有一个pleaseStop()方法从而可以在测试中途停止整个测试过程,其实现时在发布testStarted事件时,如果发现pleaseStop字段已经为true,则抛出StoppedByUserException,当Runner接收到该异常后,将该异常直接抛出。

事实上,ParentRunner在发布事件时,并不直接和RunNotifier打交道,而是会用EachTestNotifier类对其进行封装,该类只是对MultipleFailureException做了处理,其他只是一个简单的代理。在遇到MultipleFailureException,它会遍历内部每个Exception,并对每个Exception发布testFailure事件。当在运行@After注解的方法时抛出多个异常类(比如测试方法已经抛出异常了,@After注解方法中又抛出异常或者存在多个@After注解方法,并多个@After注解方法抛出了多个异常),此时就会构造一个MultipleFailureException,这种设计可能是出于对防止测试方法中的Exception被@After注解方法中的Exception覆盖的问题引入的。

FrameworkMethod与FrameworkField类

FrameworkMethod是对Java反射中Method的封装,它提供了对方法的验证、调用以及处理子类方法隐藏父类方法问题,其主要提供的接口如下:

 1 public Method getMethod();

 2 public Object invokeExplosively(final Object target, final Object params);

 3 public String getName();

 4 public void validatePublicVoidNoArg(boolean isStatic, List<Throwable> errors);

 5 public void validatePublicVoid(boolean isStatic, List<Throwable> errors) 

 6 public void validateNoTypeParametersOnArgs(List<Throwable> errors);

 7 @Override

 8 public boolean isShadowedBy(FrameworkMethod other);

 9 @Override

 public Annotation[] getAnnotations();

 public <T extends Annotation> T getAnnotation(Class<T> annotationType);

其中isShadowedBy()方法用于处理子类方法隐藏父类方法的问题,JUnit支持测试类存在继承关系,并且会遍历所有父类的测试方法,但是如果子类的方法隐藏了父类的方法,则父类的方法不会被执行。这里的隐藏是指当子类的方法名、所有参数类型相同时,不管是静态方法还是非静态方法,都会被隐藏。其实现如下:

 1 public boolean isShadowedBy(FrameworkMethod other) {

 2     if (!other.getName().equals(getName()))

 3         return false;

 4     if (other.getParameterTypes().length != getParameterTypes().length)

 5         return false;

; i < other.getParameterTypes().length; i++)

 7         if (!other.getParameterTypes()[i].equals(getParameterTypes()[i]))

 9             return false;

     return true;

 }

类似FrameworkMethod,FrameworkField是对Java反射中的Field的封装,它提供了对字段取值、处理隐藏父类字段的问题,其主要提供的接口如下:

 1 public String getName();

 2 @Override

 3 public Annotation[] getAnnotations();

 4 public boolean isPublic();

 5 @Override

 6 public boolean isShadowedBy(FrameworkField otherMember) {

 7     return otherMember.getName().equals(getName());

 8 }

 9 public boolean isStatic();

 public Field getField();

 public Class<?> getType();

 public Object get(Object target) 

 throws IllegalArgumentException, IllegalAccessException;

在处理隐藏问题是,它只是判断如果父类中某个字段的名和子类中某个字段的名字相同,则父类中的字段不会被JUnit处理,即被隐藏。事实上,关于隐藏的问题,只是对JUnit识别的方法和字段有效,即有JUnit相关注解的方法字段,其他方法并不受影响(事实上也是不可能受到影响)。

TestClass类

TestClass是对Java中Class类的封装,在TestClass构造过程中,它会收集所有传入Class实例中具有注释的字段和方法,它会搜索类的所有继承结构。因而TestClass的成员如下:

 private final Class<?> fClass;

 private Map<Class<?>, List<FrameworkMethod>> fMethodsForAnnotations;

 private Map<Class<?>, List<FrameworkField>> fFieldsForAnnotations;

并且这些成员在TestClass构造完后即已经初始化完成。在所有注解的收集过程中,它对@Before和@BeforeClass有一个特殊的处理,即父类中@Before和@BeforeClass的注解方法总是在之类之前,从而保证父类的@Before和@BeforeClass的注解方法会在子类的这些注解方法之前执行。而对@After和@AfterClass的注解方法没有做处理,因而保持了之类的@After和@AfterClass注解方法会在父类的这些注解方法之前执行。这段特殊逻辑是通过以下代码实现的(在addToAnnotationLists()方法中,其中runsTopToBottom()方法形象的表达了这个意思):

 if (runsTopToBottom(type))

 , member);

 else

     members.add(member);

在获得测试类中所有注解的方法和字段的Map后,TestClass提供了对Annotation对应的方法和字段的查询接口:

 public List<FrameworkMethod> getAnnotatedMethods(

             Class<? extends Annotation> annotationClass);

 public List<FrameworkField> getAnnotatedFields(

             Class<? extends Annotation> annotationClass);

 public <T> List<T> getAnnotatedFieldValues(Object test,

             Class<? extends Annotation> annotationClass, 

 Class<T> valueClass);
以及测试类相关的信息,如Class实例、名字、测试类中具有的Annotation等:
 public Class<?> getJavaClass();

 public String getName();

 public Constructor<?> getOnlyConstructor();

 public Annotation[] getAnnotations();

 public boolean isANonStaticInnerClass();

Runner、ParentRunner与BlockJUnit4ClassRunner类

Runner是JUnit中对所有Runner的抽象,它只包括三个方法:

 public abstract class Runner implements Describable {

     public abstract Description getDescription();

     public abstract void run(RunNotifier notifier);

     public int testCount() {

         return getDescription().testCount();

     }

 }

其中getDescription()的实现已经在Description相关的小节中做过计算了,不在重复,testCount()方法很简单,也已经实现了,因而本节主要介绍run()方法的运行过程,而该方法的实现则是在ParentRunner中。

用ParentRunner命名这个Runner是想表达这是一个在测试方法树中具有子节点的节点,它的子节点可以是测试方法(BlockJUnit4ClassRunner)或者Runner(Suite)。ParentRunner以测试类Class实例作为构造函数的参数,在构造函数内部用TestClass对测试类进行封装,并对一些那些规定的方法做验证:

1.       @BeforeClass和@AfterClass注解的方法必须是public,void,static,无参

 validatePublicVoidNoArgMethods(BeforeClass.class, true, errors);

 validatePublicVoidNoArgMethods(AfterClass.class, true, errors);

2.       对有@ClassRule修饰的字段,必须是public,static,并且该字段的实例必须是实现了TestRule接口的。为了兼容性,也可以实现MethodRule接口。

在验证过程中,ParentRunner通过一个List<Throwable>收集所有的验证错误信息,如果存在错误信息,则验证不通过,ParentRunner将抛出一个InitializationError的Exception,该Exception中包含了所有的错误信息,一般在这种情况下,会创建一个ErrorReportingRunner返回以处理验证出错的问题,该Runner将在下面的小节中详细介绍。

在Runner构造完成后,就可以调用run()方法运行该Runner了:

 1 @Override

 2 public void run(final RunNotifier notifier) {

 3     EachTestNotifier testNotifier= new EachTestNotifier(notifier, getDescription());

 5     try {

 6         Statement statement= classBlock(notifier);

 7         statement.evaluate();

 8     } catch (AssumptionViolatedException e) {

 9         testNotifier.fireTestIgnored();

     } catch (StoppedByUserException e) {

         throw e;

     } catch (Throwable e) {

         testNotifier.addFailure(e);

     }

 }

该方法的核心是构造一个Statement实例,然后调用该实例的evaluate()方法。在JUnit中,Statement是一个类链表,一个Runner的执行过程就是这个Statement类链表的执行过程。ParentRunner对Statement类链表的构造主要是对测试类级别的构造,如@BeforeClass、@AfterClass、@ClassRule等执行Statement:

 1 protected Statement classBlock(final RunNotifier notifier) {

 2     Statement statement= childrenInvoker(notifier);

 3     statement= withBeforeClasses(statement);

 4     statement= withAfterClasses(statement);

 5     statement= withClassRules(statement);

 6     return statement;

 7 }

 8 protected Statement childrenInvoker(final RunNotifier notifier) {

 9     return new Statement() {

         @Override

         public void evaluate() {

             runChildren(notifier);

         }

     };

 }

 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();

 }

 private List<T> getFilteredChildren() {

     if (fFilteredChildren == null)

         fFilteredChildren = new ArrayList<T>(getChildren());

     return fFilteredChildren;

 }

 protected abstract List<T> getChildren();

 protected abstract void runChild(T child, RunNotifier notifier);

其中getChildren()、runChild()方法由子类实现。

 1 protected Statement withBeforeClasses(Statement statement) {

 2     List<FrameworkMethod> befores= fTestClass

 3             .getAnnotatedMethods(BeforeClass.class);

 4     return befores.isEmpty() ? statement :

 5         new RunBefores(statement, befores, null);

 6 }

 7 protected Statement withAfterClasses(Statement statement) {

 8     List<FrameworkMethod> afters= fTestClass

 9             .getAnnotatedMethods(AfterClass.class);

     return afters.isEmpty() ? statement : 

         new RunAfters(statement, afters, null);

 }

 private Statement withClassRules(Statement statement) {

     List<TestRule> classRules= classRules();

     return classRules.isEmpty() ? statement :

         new RunRules(statement, classRules, getDescription());

 }

 protected List<TestRule> classRules() {

     return fTestClass.getAnnotatedFieldValues(null, 

         ClassRule.class, TestRule.class);

 }

关于Statement将在下一节中详细讲,不过这里从Statement的构造过程可以看出Rule的执行要先于@BeforeClass注解方法或晚于@AfterClass注解方法。

在ParentRunner关于执行方法的实现中,还有一个对每个测试方法Statement链的执行框架的实现,其主要功能是加入事件发布和对异常的处理逻辑,从这里的Statement实例是一个测试方法的运行整体,它包括了@Before注解方法、@After注解方法以及@Rule注解字段的TestRule实例的运行过程,因而testStarted事件的发布是在@Before方法运行之前,而testFinished事件的发布是在@After方法运行之后:

 1 protected final void runLeaf(Statement statement, Description description,    RunNotifier notifier) {

 3     EachTestNotifier eachNotifier= new EachTestNotifier(notifier, description);

 5     eachNotifier.fireTestStarted();

 6     try {

 7         statement.evaluate();

 8     } catch (AssumptionViolatedException e) {

 9         eachNotifier.addFailedAssumption(e);

     } catch (Throwable e) {

         eachNotifier.addFailure(e);

     } finally {

         eachNotifier.fireTestFinished();

     }

 }

ParentRunner还实现Filterable接口和Sortable接口,不过这里很奇怪的实现时为什么sorter要保存成字段,感觉这个完全可以通过方法参数实现,而filteredChildren字段的实现方式在多线程环境中运行的话貌似也会出问题。Filter类主要提供一个shouldRun()接口以判断传入的Description是否可以运行,若否,则将该Description从ParentRunner中移除;否则,将该Filter应用到该child中,以处理child可能是Filterable实例(ParentRunner)的问题,从而以递归、先根遍历的方式遍历测试实例树上的所有节点,若一个父节点的所有子节点都被过滤了,则抛出NoTestRemainException:

 1 public void filter(Filter filter) throws NoTestsRemainException {

 2     for (Iterator<T> iter = getFilteredChildren().iterator(); 

 3                         iter.hasNext(); ) {

 4         T each = iter.next();

 5         if (shouldRun(filter, each))

 6             try {

 7                 filter.apply(each);

 8             } catch (NoTestsRemainException e) {

 9                 iter.remove();

             }

         else

             iter.remove();

     }

     if (getFilteredChildren().isEmpty()) {

         throw new NoTestsRemainException();

     }

 }

 private boolean shouldRun(Filter filter, T each) {

     return filter.shouldRun(describeChild(each));

 }

JUnit中提供几种默认实现的Filter:1. ALL不做任何过滤;2. matchMethodDescription只保留某个指定的测试方法。

 1 public static Filter ALL= new Filter() {

 2     @Override

 3     public boolean shouldRun(Description description) {

 4         return true;

 5     }

 6     @Override

 7     public String describe() {

 8         return "all tests";

 9     }

     @Override

     public void apply(Object child) throws NoTestsRemainException {

         // 因为不会做任何过滤行为,因而不需要应用到子节点中

     }

     @Override

     public Filter intersect(Filter second) {

         return second; // 因为本身没有任何过滤行为,所以可以直接返回传入的Filter

     }

 };

 public static Filter matchMethodDescription(final Description desiredDescription) {

     return new Filter() {

         @Override

         public boolean shouldRun(Description description) {

             if (description.isTest())

                 return desiredDescription.equals(description);

             // explicitly check if any children want to run

             for (Description each : description.getChildren())

                 if (shouldRun(each))

                     return true;

             return false;                    

         }

         @Override

         public String describe() {

             return String.format("Method %s", desiredDescription.getDisplayName());

         }

     };

 }

Sorter类实现Comparator接口,ParentRunner通过其compare()方法构造和ParentRunner子节点相关的Comparator实例,并采用后根递归遍历的方式对测试方法树中的所有测试方法进行排序,因而这里只会排序同一个节点下的所有子节点,而节点之间的顺序不会受影响。

 1 public void sort(Sorter sorter) {

 2     fSorter= sorter;

 3     for (T each : getFilteredChildren())

 4         sortChild(each);

 5     Collections.sort(getFilteredChildren(), comparator());

 6 }

 7 private Comparator<? super T> comparator() {

 8     return new Comparator<T>() {

 9         public int compare(T o1, T o2) {

             return fSorter.compare(describeChild(o1), describeChild(o2));

         }

     };

 }

最后ParentRunner还提供了一个RunnerScheduler的接口字段,以控制JUnit测试方法的执行过程,我们可以注入一个使用多线程方式运行每个测试方法的RunnerScheduler,不过从代码上看,貌似JUnit对多线程的支持并不好,所以这个接口的扩展目前来看我还找不到什么用途:

 public interface RunnerScheduler {

     void schedule(Runnable childStatement);

     void finished();

 }

BlockJUnit4ClassRunner节点下所有的子节点都是测试方法,它是JUnit中运行测试方法的核心Runner,它实现了ParentRunner中没有实现的几个方法:

  1 @Override

  2 protected List<FrameworkMethod> getChildren() {

  3     return computeTestMethods();

  4 }

  5 protected List<FrameworkMethod> computeTestMethods() {

  6     return getTestClass().getAnnotatedMethods(Test.class);

  7 }

  8 @Override

  9 protected void runChild(final FrameworkMethod method, RunNotifier notifier) {

 11     Description description= describeChild(method);

 12     if (method.getAnnotation(Ignore.class) != null) {

 13         notifier.fireTestIgnored(description);

 14     } else {

 15         runLeaf(methodBlock(method), description, notifier);

 16     }

 17 }

 18 protected Statement methodBlock(FrameworkMethod method) {

 19     Object test;

 20     try {

 21         test= new ReflectiveCallable() {

 22             @Override

 23             protected Object runReflectiveCall() throws Throwable {

 24                 return createTest();

 25             }

 26         }.run();

 27     } catch (Throwable e) {

 28         return new Fail(e);

 29     }

 30     Statement statement= methodInvoker(method, test);

 31     statement= possiblyExpectingExceptions(method, test, statement);

 32     statement= withPotentialTimeout(method, test, statement);

 33     statement= withBefores(method, test, statement);

 34     statement= withAfters(method, test, statement);

 35     statement= withRules(method, test, statement);

 36     return statement;

 37 } //这个方法的实现可以看出每个测试方法运行时都会重新创建一个新的测试类实例,这也可能是@BeforeClass、AfterClass、@ClassRule需要静态的原因吧,因为静态的话,每次类实例的重新创建对其结果都不会有影响。

 38 另,从这里对Statement的构建顺序,JUnit对TestRule的运行也要在@Before注解方法之前或@After注解方法之后

 39 protected Object createTest() throws Exception {

 40     return getTestClass().getOnlyConstructor().newInstance();

 41 }

 42 protected Statement methodInvoker(FrameworkMethod method, Object test) {

 43     return new InvokeMethod(method, test);

 44 }

 45 protected Statement possiblyExpectingExceptions(FrameworkMethod method, object test, Statement next) {

 47     Test annotation= method.getAnnotation(Test.class);

 48     return expectsException(annotation) ? new ExpectException(next,

 49             getExpectedException(annotation)) : next;

 50 }

 51 private Class<? extends Throwable> getExpectedException(Test annotation) {

 52     if (annotation == null || annotation.expected() == None.class)

 53         return null;

 54     else

 55         return annotation.expected();

 56 }

 57 private boolean expectsException(Test annotation) {

 58     return getExpectedException(annotation) != null;

 59 }

 60 protected Statement withPotentialTimeout(FrameworkMethod method,

 61         Object test, Statement next) {

 62     long timeout= getTimeout(method.getAnnotation(Test.class));

 ? new FailOnTimeout(next, timeout) : next;

 64 }

 65 private long getTimeout(Test annotation) {

 66     if (annotation == null)

;

 68     return annotation.timeout();

 69 }

 70 protected Statement withBefores(FrameworkMethod method, Object target,

 71         Statement statement) {

 72     List<FrameworkMethod> befores= getTestClass().getAnnotatedMethods(

 73             Before.class);

 74     return befores.isEmpty() ? statement : new RunBefores(statement,

 75             befores, target);

 76 }

 77 protected Statement withAfters(FrameworkMethod method, Object target,

 78         Statement statement) {

 79     List<FrameworkMethod> afters= getTestClass().getAnnotatedMethods(

 80             After.class);

 81     return afters.isEmpty() ? statement : new RunAfters(statement, 

 82             afters, target);

 83 }

 84 private Statement withRules(FrameworkMethod method, Object target,

 85         Statement statement) {

 86     Statement result= statement;

 87     result= withMethodRules(method, target, result);

 88     result= withTestRules(method, target, result);

 89     return result;

 90 }

 91 private Statement withMethodRules(FrameworkMethod method, Object target,

 92         Statement result) {

 93     List<TestRule> testRules= getTestRules(target);

 94     for (org.junit.rules.MethodRule each : getMethodRules(target))

 95         if (! testRules.contains(each))

 96             result= each.apply(result, method, target);

 97     return result;

 98 }

 99 private List<org.junit.rules.MethodRule> getMethodRules(Object target) {

     return rules(target);

 }

 protected List<org.junit.rules.MethodRule> rules(Object target) {

     return getTestClass().getAnnotatedFieldValues(target, Rule.class,

             org.junit.rules.MethodRule.class);

 }

 private Statement withTestRules(FrameworkMethod method, Object target,

         Statement statement) {

     List<TestRule> testRules= getTestRules(target);

     return testRules.isEmpty() ? statement :

         new RunRules(statement, testRules, describeChild(method));

 }

 protected List<TestRule> getTestRules(Object target) {

     return getTestClass().getAnnotatedFieldValues(target,

             Rule.class, TestRule.class);

 }

在验证方面,BlockJUnit4ClassRunner也加入了一些和自己相关的验证:

 @Override

 protected void collectInitializationErrors(List<Throwable> errors) {

     super.collectInitializationErrors(errors);

     validateNoNonStaticInnerClass(errors);

     validateConstructor(errors);

     validateInstanceMethods(errors);

     validateFields(errors);

 }

1.       如果测试类是一个类的内部类,那么该测试类必须是静态的:

 protected void validateNoNonStaticInnerClass(List<Throwable> errors) {

     if (getTestClass().isANonStaticInnerClass()) {

         String gripe= "The inner class " + getTestClass().getName()

                 + " is not static.";

         errors.add(new Exception(gripe));

     }

 }

2.       测试类的构造函数必须有且仅有一个无参的构造函数(事实上关于只有一个构造函数的验证在构造TestClass实例的时候已经做了,因而这里真正起作用的知识对无参的验证):

 1 protected void validateConstructor(List<Throwable> errors) {

 2     validateOnlyOneConstructor(errors);

 3     validateZeroArgConstructor(errors);

 4 }

 5 protected void validateOnlyOneConstructor(List<Throwable> errors) {

 6     if (!hasOneConstructor()) {

 7         String gripe= "Test class should have exactly one public constructor";

 8         errors.add(new Exception(gripe));

 9     }

 }

 protected void validateZeroArgConstructor(List<Throwable> errors) {

     if (!getTestClass().isANonStaticInnerClass()

             && hasOneConstructor()

 )) {

         String gripe= "Test class should have exactly one public zero-argument constructor";

         errors.add(new Exception(gripe));

     }

 }

 private boolean hasOneConstructor() {

 ;

 }

3.       @Before、@After、@Test注解的方法必须是public,void,非静态,不带参数:

 1 protected void validateInstanceMethods(List<Throwable> errors) {

 2     validatePublicVoidNoArgMethods(After.class, false, errors);

 3     validatePublicVoidNoArgMethods(Before.class, false, errors);

 4     validateTestMethods(errors);

)

 6         errors.add(new Exception("No runnable methods"));

 7 }

 8 protected void validateTestMethods(List<Throwable> errors) {

 9     validatePublicVoidNoArgMethods(Test.class, false, errors);

 }

4.       带有@Rule注解的字段必须是public,非静态,实现了TestRule接口或MethodRule接口。

 private void validateFields(List<Throwable> errors) {

     RULE_VALIDATOR.validate(getTestClass(), errors);

 }

JUnit核心执行的序列图

写了好几天,终于把JUnit核心的执行所有代码分析完了,不过发现写的那么细,很多东西其实很难表达,因而贴了很多代码,感觉写的挺乱的,所以画一张序列图吧,感觉很多时候还是图的表达效果更好一些,要我看那么一大段的问题,也感觉挺烦的。

Suite与Parameterized

Suite是其子节点是Runner的Runner,其内部保存了一个Runner的List。Suite的功能实现很简单,因为它将大部分的方法代理给了其内部Runner实例:

 1 private final List<Runner> fRunners;

 2 @Override

 3 protected List<Runner> getChildren() {

 4     return fRunners;

 5 }

 6 @Override

 7 protected Description describeChild(Runner child) {

 8     return child.getDescription();

 9 }

 @Override

 protected void runChild(Runner runner, final RunNotifier notifier) {

     runner.run(notifier);

 }

Suite重点在于如何构建一个Suite,Suite提供两个构造函数:

1.       提供一个带SuiteClasses注解的类,所有测试类由SuiteClasses指定,而klass类作为这个Suite的根类。此时一般所有的测试类是klass的内部类,因而可以通过@RunWith指定运行klass类的Runner是Suite,然后用SuiteClasses注解指定可以作为测试类的类。

 1 public Suite(Class<?> klass, RunnerBuilder builder) throws InitializationError {

 3     this(builder, klass, getAnnotatedClasses(klass));

 4 }

 5 protected Suite(RunnerBuilder builder, Class<?> klass, Class<?>[] suiteClasses) throws InitializationError {

 7     this(klass, builder.runners(klass, suiteClasses));

 8 }

 9 @Retention(RetentionPolicy.RUNTIME)

 @Target(ElementType.TYPE)

 @Inherited

 public @interface SuiteClasses {

     public Class<?>[] value();

 }

 private static Class<?>[] getAnnotatedClasses(Class<?> klass) throws InitializationError {

     SuiteClasses annotation= klass.getAnnotation(SuiteClasses.class);

     if (annotation == null)

         throw new InitializationError(String.format("class '%s' must have a SuiteClasses annotation", klass.getName()));

     return annotation.value();

 }

2.       在有些情况下,我们需要运行多个没有相关的测试类,此时这些测试类没有一个公共的根类的Suite,则需要使用一下的构造函数(此时Suite的getName()返回”null”,即其Description的displayName的值为”null”,关于RunnerBuilder将会在后面的文章中介绍):

 1 public Suite(RunnerBuilder builder, Class<?>[] classes) throws InitializationError {

 3     this(null, builder.runners(null, classes));

 4 }

 5 protected Suite(Class<?> klass, List<Runner> runners) throws InitializationError {

 7     super(klass);

 8     fRunners = runners;

 9 }

Parameterized继承自Suite,它类似BlockJUnit4ClassRunner是对一个测试类的运行过程的封装,但是它支持在测试类中定义一个获得参数数组的一个列表,从而可以为构造该测试类提供不同的参数值以进行多次测试。因而Parameterized这个Runner其实就是根据参数数组列表的个数创建多个基于该测试类的Runner,并运行所有这些Runner中测试方法。

由于这个测试类的构造函数是带参的,而BlockJUnit4ClassRunner则限制其测试类必须是不带参的,因而Parameterized需要创建自己的Runner,它集成自BlockJUnit4ClassRunner,除了构造函数的差别,Parameterized的根节点是该测试类本身,它处理@BeforeClass、@AfterClass、@ClassRule的注解问题,因而其子节点的Runner不需要重新对其做处理了,因而在集成的Runner中应该避免这些方法、字段重复执行。

 1 private class TestClassRunnerForParameters extends BlockJUnit4ClassRunner {

 3     private final int fParameterSetNumber;

 4     private final List<Object[]> fParameterList;

 5     TestClassRunnerForParameters(Class<?> type, List<Object[]> parameterList, int i) throws InitializationError {

 8         super(type);

 9         fParameterList= parameterList;

         fParameterSetNumber= i; //参数数组列表中的位置

     }

     @Override

     public Object createTest() throws Exception {

         return getTestClass().getOnlyConstructor().newInstance(

                 computeParams());//带参创建测试类实例

     }

     private Object[] computeParams() throws Exception {

         try {

             return fParameterList.get(fParameterSetNumber);

         } catch (ClassCastException e) {

             throw new Exception(String.format(

                     "%s.%s() must return a Collection of arrays.",

                     getTestClass().getName(), getParametersMethod(

                             getTestClass()).getName()));

         }

     }

     @Override

     protected String getName() {

         return String.format("[%s]", fParameterSetNumber);

     }

     @Override

     protected String testName(final FrameworkMethod method) {

         return String.format("%s[%s]", method.getName(),

                 fParameterSetNumber);

     }

     @Override

     protected void validateConstructor(List<Throwable> errors) {

         validateOnlyOneConstructor(errors);//去除不带参构造函数验证

     }

     @Override

     protected Statement classBlock(RunNotifier notifier) {

         return childrenInvoker(notifier);//不处理@BeforeClass、

 //@AfterClass、@ClassRule等注解

     }

     @Override

     protected Annotation[] getRunnerAnnotations() {

 ];//去除测试类的Annotation,这些应该在Parameterized中处理

     }

 }

Parameterized对Suite的行为改变只是在创建Runner集合的过程,Parameterized通过类中查找@Parameters注解的静态方法获得参数数组列表,并更具这个参数数组列表创建TestClassRunnerForParameters的集合:

 1 @Retention(RetentionPolicy.RUNTIME)

 2 @Target(ElementType.METHOD)

 3 public static @interface Parameters {

 4 }

 5 public Parameterized(Class<?> klass) throws Throwable {

 6     super(klass, Collections.<Runner>emptyList());

 7     List<Object[]> parametersList= getParametersList(getTestClass());

; i < parametersList.size(); i++)

 9         runners.add(new TestClassRunnerForParameters(getTestClass().getJavaClass(), parametersList, i));

 }

 private List<Object[]> getParametersList(TestClass klass)

         throws Throwable {

     return (List<Object[]>) getParametersMethod(klass).invokeExplosively(null);

 }

 private FrameworkMethod getParametersMethod(TestClass testClass)

         throws Exception {

     List<FrameworkMethod> methods= testClass.getAnnotatedMethods(Parameters.class);

     for (FrameworkMethod each : methods) {

         int modifiers= each.getMethod().getModifiers();

         if (Modifier.isStatic(modifiers) && 

                 Modifier.isPublic(modifiers))

             return each;

     }

     throw new Exception("No public static parameters method on class " + testClass.getName());

 }

一个简单的Parameterized测试类如下,不过如果在Eclipse中单独的运行testEqual()测试方法会出错,因为Eclipse在Filter传入的方法名为testEqual,而在Parameterized中这个方法名已经被改写成testEqual[i]了,因而在Filter过程中,所有的测试方法都被过滤掉了,此时会抛NoTestRemainException,而在Eclipse中出现的则是InitializationError的Exception,这里也是Eclipse中JUnit的插件没有做好,它并没有给出Failure类的详细信息:

 1 public class ParameterizedTest {

 2     @Parameters

 3      public static List<Object[]> data() {

 4          return Arrays.asList(new Object[][] {

 }, 

 }

 7          });

 8      }

 9      @BeforeClass

      public static void beforeClass() {

          System.out.println(".testing.");

      }

      private final int input;

      private final int expected;

      public ParameterizedTest(int input, int expected) {

          this.input = input;

          this.expected = expected;

      }

      @Test

      public void testEqual() {

          Assert.assertEquals(expected, compute(input));

      }

      public int compute(int input) {

 ) {

              return input;

          }

 ) {

 ;

          }

 );

      }

 }

ErrorReportingRunner和IgnoredClassRunner

关于JUnit4,还剩下最后两个Runner,分别是ErrorReportingRunner和IgnoredClassRunner,为了编程模型的统一(这是一个非常好的设计想法,将各种变化都封装在Runner中),JUnit中即使一个Runner实例创建失败或是该测试类有@Ignored的注解,在这两种情况中,JUnit分别通过ErrorReportingRunner和IgnoredClassRunner去表达。在ErrorReportingRunner中,为每个Exception发布测试失败的信息;IgnoredClassRunner则只是发布testIgnored事件:

 1 public class ErrorReportingRunner extends Runner {

 2     private final List<Throwable> fCauses;

 3     private final Class<?> fTestClass;

 4     public ErrorReportingRunner(Class<?> testClass, Throwable cause) {

 5         fTestClass= testClass;

 6         fCauses= getCauses(cause);

 7     }

 8     @Override

 9     public Description getDescription() {

         Description description= Description.createSuiteDescription(fTestClass);

         for (Throwable each : fCauses)

             description.addChild(describeCause(each));

         return description;

     }

     @Override

     public void run(RunNotifier notifier) {

         for (Throwable each : fCauses)

             runCause(each, notifier);

     }

     @SuppressWarnings("deprecation")

     private List<Throwable> getCauses(Throwable cause) {

         if (cause instanceof InvocationTargetException)

             return getCauses(cause.getCause());

         if (cause instanceof InitializationError)

             return ((InitializationError) cause).getCauses();

         if (cause instanceof org.junit.internal.runners.InitializationError)

             return ((org.junit.internal.runners.InitializationError) cause)

                     .getCauses();

         return Arrays.asList(cause);

     }

     private Description describeCause(Throwable child) {

         return Description.createTestDescription(fTestClass,

                 "initializationError");

     }

     private void runCause(Throwable child, RunNotifier notifier) {

         Description description= describeCause(child);

         notifier.fireTestStarted(description);

         notifier.fireTestFailure(new Failure(description, child));

         notifier.fireTestFinished(description);

     }

 }

 public class IgnoredClassRunner extends Runner {

     private final Class<?> fTestClass;

     public IgnoredClassRunner(Class<?> testClass) {

         fTestClass= testClass;

     }

     @Override

     public void run(RunNotifier notifier) {

         notifier.fireTestIgnored(getDescription());

     }

     @Override

     public Description getDescription() {

         return Description.createSuiteDescription(fTestClass);

     }

 }

写在最后的话

写了一个周末了,这一篇终于是写完了,初次尝试将阅读框架源码以文字的形式表达出来,确实不好写,感觉自己写的太详细了,也贴了太多源码,因为有些时候感觉源码比文字更有表达能力,不过太多的源码就把很多实质的东西掩盖了,然后文章看起来也没有什么大的价值干,而且太长了,看到那么多的东西,要我自己看到也就有不想看的感觉,1万多字啊,呵呵。总之以后慢慢改进吧,这一篇就当是练习了,不想复工了,也没那么多的时间重写。。。。。。



junit4X系列--Runner解析的更多相关文章

  1. XML系列之--解析电文格式的XML(二)

    上一节介绍了XML的结构以及如何创建.讲到了XML可作为一种简单文本存储数据,把数据存储起来,以XML的方式进行传递.当接收到XML时,必不可少的就是对其进行解析,捞取有效数据,或者将第三方数据以节点 ...

  2. junit4X系列源码--Junit4 Runner以及test case执行顺序和源代码理解

    原文出处:http://www.cnblogs.com/caoyuanzhanlang/p/3534846.html.感谢作者的无私分享. 前一篇文章我们总体介绍了Junit4的用法以及一些简单的测试 ...

  3. [转]Android自定义控件三部曲系列完全解析(动画, 绘图, 自定义View)

    来源:http://blog.csdn.net/harvic880925/article/details/50995268 一.自定义控件三部曲之动画篇 1.<自定义控件三部曲之动画篇(一)—— ...

  4. Thrift之TProtocol系列TJSONProtocol解析

    在了解JSON协议之前,朋友们可以先去了解一下JSON的基础知识,和ASCII基本分布,关于JSON一些常识请见这里; JSON (JavaScript Object Notation)是一种数据交换 ...

  5. Thrift之TProtocol系列TBinaryProtocol解析

    首先看一下Thrift的整体架构,如下图: 如图所示,黄色部分是用户实现的业务逻辑,褐色部分是根据thrift定义的服务接口描述文件生成的客户端和服务器端代码框架(前篇2中已分析了thrift ser ...

  6. Junit4X系列--hamcrest的使用

    OK,在前面的一系列博客里面,我整理过了Assert类下面常用的断言方法,比如assertEquals等等,但是org.junit.Assert类下还有一个方法也用来断言,而且更加强大.这就是我们这里 ...

  7. junit4X系列--Assert与Hamcrest

    原文出处:http://www.blogjava.net/DLevin/archive/2012/05/12/377960.html.感谢作者无私分享 到目前,JUnit4所有的核心源码都已经讲解过了 ...

  8. junit4X系列源码--总体介绍

    原文出处:http://www.cnblogs.com/caoyuanzhanlang/p/3530267.html.感谢作者的无私分享. Junit是一个可编写重复测试的简单框架,是基于Xunit架 ...

  9. junit4X系列--Builder、Request与JUnitCore

    原文出处:http://www.blogjava.net/DLevin/archive/2012/05/12/377957.html.感谢作者的无私分享. 初次用文字的方式记录读源码的过程,不知道怎么 ...

随机推荐

  1. PyQt4中的Treeview

    import sys from PyQt4 import QtCore, QtGui from qyolk import Ui_QYolk from yolk import yolklib class ...

  2. 【树链剖分】洛谷P3379 树链剖分求LCA

    题目描述 如题,给定一棵有根多叉树,请求出指定两个点直接最近的公共祖先. 输入输出格式 输入格式: 第一行包含三个正整数N.M.S,分别表示树的结点个数.询问的个数和树根结点的序号. 接下来N-1行每 ...

  3. 如何使用 Q#

    Q# 是微软的量子语言,很厉害,所以本文告诉大家如何入门,如何配置. 介绍 很多新的计数机技术都在很多年前就有人提出,量子计算就是其中一个.量子计算在 1980 年就被 Richard Feynman ...

  4. react 开发知识准备

    react react使用教程 babel babel 可用于ES6转换为ES5,jsx转换为原生js. ES6 ES6 语法 webpack webpack打包工具,它把不同的.相互依赖的静态资源都 ...

  5. Memory Map

    计算机最重要的功能单元之一是Memory.Memory是众多存储单元的集合,为了使CPU准确地找到存储有某个信息的存储单元,必须为这些单元分配一个相互区别的“身份证号”,这个“身份证号”就是地址编码. ...

  6. fastboot模式

    快速启动. 在安卓手机中fastboot是一种比recovery更底层的刷机模式. fastboot是一种线刷,就是使用USB数据线连接手机的一种刷机模式. recovery是一种卡刷,就是将刷机包放 ...

  7. Android基础_web通信

    一.发展史 1G 模拟制式手机,只能进行语音通话2G 数字制式手机,增加接收数据等功能3G 智能手机,它已经成了集语音通信和多媒体通信相结合,并且包括图像.音乐.网页浏览.电话会议以及其它一些信息服务 ...

  8. tomcat server location 地址的修改

    如果是目录是灰色,那么请先删除现有的项目,然后Clean 修改之后,发布的目录是.具体目录与tomcat 安装目录相关 access_log

  9. MongoDB建立主从复制小案例(一主一从)

    花了两天学习了mongoDB, 今天接触到了mongo的主从配置, 把它记下来 1. 开启两个mongo服务器(用于一主一从, 没有加安全验证相关参数 : 可以使用mongd-help查看) mong ...

  10. bzoj:4762: 最小集合

    原题链接:http://www.lydsy.com/JudgeOnline/problem.php?id=4762 mark一下,有空要好好弄懂 #include<cstdio> #inc ...