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的整体框架有了全面的认识。总体来说各个包分工明确,设计上采用了必要的设计模式来增强了扩展性和重用性,很值得学习和借鉴。

时间: 2024-12-02 05:32:24

JUnit源码分析(二)的相关文章

JUnit源码分析(四)——从Decorator模式说起

其实我这系列小文,名为源码分析,其实是自己读<设计模式>的读书笔记.Decorator模式在java的IO库中得到应用,java的IO库看起来复杂,其实理解了Decorator模式再回头看可以很好理解并使用.     Decorator模式,也就是装饰器模式,是对象结构型模式之一. 1.意图:动态地给一个对象添加一些额外的职责.给对象添加功能,我们首先想到的是继承,但是如果每增一个功能都需要继承,类的继承体系将无可避免地变的庞大和难以理解.面向对象设计的原则:优先使用组合,而非继承,继承的层次

JUnit源码分析(三)

三.微观--执行流程与代码风格 来过一遍JUnit的执行流程吧,这样你就能对JUnit有个清晰的认识,虽然作为一个使用者这完全是不必要的.从<JUnit in Action>直接拿来一张JUnit流程图. 哦,也许你看晕了,我来当下导游好了.上面已经提到了TestRunner是BaseTestRunner的子类,在三个不同的ui包中各有一个TestRunner.这里我们仅以junit.textui包中的为例. TestRunner作为入口程序是怎么被启动的呢?习惯了使用容器的我们现在也许很少考

JUnit源码分析 (三)——Template Method模式

在JUnit执行测试时,我们经常需要初始化一些环境供测试代码使用,比如数据库连接.mock对象等等,这些初始化代码应当在每一个测试之前执行并在测试方法运行后清理.在JUnit里面就是相应的setUp和tearDown方法.如果没有这两个方法,那么我们要在每个测试方法的代码内写上一大堆重复的初始化和清理代码,这是多么愚蠢的做法.那么JUnit是怎么让setUp和tearDown在测试执行前后被调用的呢?     如果你查看下TestCase方法,你会发现TestCase和TestSuite的run

JUnit源码分析(二)——观察者模式

    我们知道JUnit支持不同的使用方式:swt.swing的UI方式,甚至控制台方式,那么对于这些不同的UI我们如何提供统一的接口供它们获取测试过程的信息(比如出现的异常信息,测试成功,测试失败的代码行数等等)?我们试想一下这个场景,当一个error或者exception产生的时候,测试能够马上通知这些UI客户端:发生错误了,发生了什么错误,错误是什么等等.显而易见,这是一个订阅-发布机制应用的场景,应当使用观察者模式.那么什么是观察者模式呢? 观察者模式(Observer) Observ

关于Junit源码的一些探索

Junit介绍 Junit 是由 Erich Gamma 和 Kent Beck 编写的一个开源的单元测试框架,主要用于白盒测试.Junit 的设计精简,易学易用,但是功能却非常强大. 在Junit3中,使用时只需继承TestCase类,并且 1. 测试方法名以test开头,返回void,方法中没有参数 2. 使用方法setUp()做初始化工作,使用方法tearDown()做清理工作 3. 使用Assert类的方法来判断测试用例结果 Junit源码分析 Junit的流程图: Junit的完整生命

Hhadoop-2.7.0中HDFS写文件源码分析(二):客户端实现之DFSPacket

一.简介       HDFS在数据传输过程中,针对数据块Block,不是整个block进行传输的,而是将block切分成一个个的数据包进行传输.而DFSPacket就是HDFS数据传输过程中对数据包的抽象. 二.实现       HDFS客户端在往DataNodes节点写数据时,会以数据包packet的形式写入,且每个数据包包含一个包头,n个连续的校验和数据块checksum chunks和n个连续的实际数据块 actual data chunks,每个校验和数据块对应一个实际数据块,被用来做

TOMCAT源码分析——生命周期管理(二)

前言 我在<TOMCAT源码分析--生命周期管理(一)>一文中介绍了TOMCAT生命周期类接口设计.JMX.容器以及基于容器的事件与监听等内容,本文将接着介绍Tomcat7.0中容器生命周期的管理. 容器生命周期 每个容器都会有自身的生命周期,其中也涉及状态的迁移,以及伴随的事件生成,本节详细介绍Tomcat中的容器生命周期实现.所有容器的转态转换(如新疆.初始化.启动.停止等)都是由外到内,由上到下进行,即先执行父容器的状态转换及相关操作,然后再执行子容器的转态转换,这个过程是层层迭代执行的

HBase源码分析之MemStore的flush发起时机、判断条件等详情(二)

        在<HBase源码分析之MemStore的flush发起时机.判断条件等详情>一文中,我们详细介绍了MemStore flush的发起时机.判断条件等详情,主要是两类操作,一是会引起MemStore数据大小变化的Put.Delete.Append.Increment等操作,二是会引起HRegion变化的诸如Regin的分裂.合并以及做快照时的复制拷贝等,同样会触发MemStore的flush流程.同时,在<HBase源码分析之compact请求发起时机.判断条件等详情(一

Hhadoop-2.7.0中HDFS写文件源码分析(二):客户端实现(1)

一.综述       HDFS写文件是整个Hadoop中最为复杂的流程之一,它涉及到HDFS中NameNode.DataNode.DFSClient等众多角色的分工与合作.       首先上一段代码,客户端是如何写文件的: Configuration conf = new Configuration(); FileSystem fs = FileSystem.get(conf); Path file = new Path("demo.txt"); FSDataOutputStream