下图是根据源代码分析出来的framework包中各个关键类之间的关系

Assert类提供了JUnit使用的一整套的断言，这套断言都被TestCase继承下来，Assert也变成了透明的。

Test接口是为了统一TestCase和TestSuite的类型；

TestCase里面提供了运行单元测试类的方法；

TestSuite中则提供了加载单元测试类，检验测试类格式等等的方法。

TestResult故名思意是提供存放测试结果的地方，但是在JUnit中它还带有一点控制器的功能。

TestListener接口抽象了所有测试监听者的行为，他包括添加错误和失败的方法，开始测试和结束测试的方法。在JUnit框架中有两个类实现了这个接口，一个负责结果打印的ResultPrinter类，一个是所有TestRunner的基础类BaseTestRunner类（这两个类都不在framework包中）。

 1.2      extentions包中类设计分析

 在上面我们已经提到了junit.extentions包中的内容TestSetup。来看看整个包的结构吧。

先简要的介绍下包中各个类的功能。

ActiveTestSuite对TestSuite进行了改进，使得每个test运行在一个单独的线程里面，并且只到所有的线程都结束了才会结束整个测试。

ExceptionTestCase是对TestCase进行的改进，可以方便的判断测试类是否抛出了期望的异常。

剩下的三个类，使用了装饰模式来设计的。其中TestDecorator为具体装饰类制定好了使用规则，RepeatedTest和TestSetup则是具体实现的装饰类。

那为什么extentions包中ActiveTestSuite和ExceptionTestCase没有使用装饰模式呢？原因在于装饰模式在结构上要求存在类似于组合模式的递归。而对于已有的TestCase和TestSuite来说，直接继承它们要比构建一个新的递归结构要来得快得多而且简单；并且这些增强功能都只是针对TestCase或者TestSuite。使用了装饰模式来扩展的类与以上不同的是，它们功能的增强是针对任何Test实现的。如果不采用装饰模式同样的功能要为TestCase、TestSuite以及以后的其他Test实现分别写出子类。因此使用装饰模式能够很巧妙的解决这个问题。
1.3      runner包中类设计分析

在junit.runner包。重要的是BaseTestRunner这个类，所有运行入口或者图形界面都是集成了这个类，剩下其他的类使用反射机制来将测试类加载进来，还有读取properties文件的操作。当然这部分也非常重要，如果想学习下反射机制的应用以及尝试写自己的类加载器可以阅读这部分的源码（关于反射技术后续会继续分析）。

 剩下的三个包这里也不作介绍，大部分的内容都是GUI的绘制（当然junit.textui包除外）。

 这样，对JUnit的整体框架有了全面的认识。总体来说各个包分工明确，设计上采用了必要的设计模式来增强了扩展性和重用性（其设计模式后续继续分析），很值得学习和借鉴。

JUNIT源码探秘（三）：JUNIT整体执行过程分析

在阅读Junit源码时，需要对Junit执行测试代码的整体过程比较了解，这样才能够更好的学习Junit。所以本节主要介绍下Junit的执行过程

在执行过程中使用Java Application，在执行过程中加载运行参数：

-version， 3， -port， 10115， -testLoaderClass， org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestLoader， -loaderpluginname， org.eclipse.jdt.junit.runtime， -classNames， com.wonew.junit.TestAll

当运行一个测试代码时，先new一个TestRunner对象，同时给每一个TestRunner创建一个TestResult对象

根据代码可以看出JUnit 的完整执行过程分为两步：初始化加载用例集阶段（getTest）、运行调度和结果捕捉阶段（doRun），为了方便说吗我们把这两部分分解成三个阶段：即初始化加载用例集阶段、运行调度和结果捕捉记录阶段