源码分析(二)
在上面我们已经提到了junit.extentions包中的内容TestSetup。来看看整个包的结构吧。
先简要的介绍下包中各个类的功能。ActiveTestSuite对TestSuite进行了改进,使得每个test运行在一个单独的线程里面,并且只到所有的线程都结束了才会结束整个测试。ExceptionTestCase是对TestCase进行的改进,可以方便的判断测试类是否抛出了期望的异常。而剩下的三个类,大概你看的出来是使用了装饰模式来设计的。其中TestDecorator为具体装饰类制定好了使用规则,RepeatedTest和TestSetup则是具体实现的装饰类。
那为什么extentions包中ActiveTestSuite和ExceptionTestCase没有使用装饰模式呢?原因在于装饰模式在结构上要求存在类似于组合模式的递归。而对于已有的TestCase和TestSuite来说,直接继承它们要比构建一个新的递归结构要来得快得多而且简单;并且这些增强功能都只是针对TestCase或者TestSuite。使用了装饰模式来扩展的类与以上不同的是,它们功能的增强是针对任何Test实现的。如果不采用装饰模式同样的功能要为TestCase、TestSuite以及以后的其他Test实现分别写出子类。因此使用装饰模式能够很巧妙的解决这个问题。
下面来介绍下junit.runner包。上面已经提到,对于JUnit使用者来说,它可说是完全透明的,这个包里面提供了JUnit自己的测试类加载。下面就是包中所有类的关系图。
没有什么好讲的,都是使用反射机制来将测试类加载进来,还有读取properties文件的操作。如果想学习下反射机制的应用可以阅读这部分的源码。
剩下的三个包这里也不作介绍,大部分的内容都是GUI的绘制(当然junit.textui包除外)。
JUnit中还使用了观察者模式来完成单元测试结果的自动更新(详细内容请见我关于观察者模式的文章)。
这样,对JUnit的整体框架有了全面的认识。总体来说各个包分工明确,设计上采用了必要的设计模式来增强了扩展性和重用性,很值得学习和借鉴。
在上面我们已经提到了junit.extentions包中的内容TestSetup。来看看整个包的结构吧。
先简要的介绍下包中各个类的功能。ActiveTestSuite对TestSuite进行了改进,使得每个test运行在一个单独的线程里面,并且只到所有的线程都结束了才会结束整个测试。ExceptionTestCase是对TestCase进行的改进,可以方便的判断测试类是否抛出了期望的异常。而剩下的三个类,大概你看的出来是使用了装饰模式来设计的。其中TestDecorator为具体装饰类制定好了使用规则,RepeatedTest和TestSetup则是具体实现的装饰类。
那为什么extentions包中ActiveTestSuite和ExceptionTestCase没有使用装饰模式呢?原因在于装饰模式在结构上要求存在类似于组合模式的递归。而对于已有的TestCase和TestSuite来说,直接继承它们要比构建一个新的递归结构要来得快得多而且简单;并且这些增强功能都只是针对TestCase或者TestSuite。使用了装饰模式来扩展的类与以上不同的是,它们功能的增强是针对任何Test实现的。如果不采用装饰模式同样的功能要为TestCase、TestSuite以及以后的其他Test实现分别写出子类。因此使用装饰模式能够很巧妙的解决这个问题。
下面来介绍下junit.runner包。上面已经提到,对于JUnit使用者来说,它可说是完全透明的,这个包里面提供了JUnit自己的测试类加载。下面就是包中所有类的关系图。
没有什么好讲的,都是使用反射机制来将测试类加载进来,还有读取properties文件的操作。如果想学习下反射机制的应用可以阅读这部分的源码。
剩下的三个包这里也不作介绍,大部分的内容都是GUI的绘制(当然junit.textui包除外)。
JUnit中还使用了观察者模式来完成单元测试结果的自动更新(详细内容请见我关于观察者模式的文章)。
这样,对JUnit的整体框架有了全面的认识。总体来说各个包分工明确,设计上采用了必要的设计模式来增强了扩展性和重用性,很值得学习和借鉴。