为什么JUnit里面会出现这样奇怪的依赖关系，还有违反单一职责原则的TestResult？当我看到junit.extentions包中的TestSetup时，也许我猜到了作者的用意。我们来看下TestSetup中有关的代码：
public void run(final TestResult result) {
//又看到了上面类似的匿名内部类
Protectable p= new Protectable() {
public void protect() throws Exception {
//不过这个内部类里面的实现有所不同
setUp();
basicRun(result);
tearDown();
}
};
//调用了TestResult中的runProtected方法来执行上面的实现
result.runProtected(this， p);
}
这个类的产生是为了弥补TestCase类的一个小小的缺陷（具体请见下部分）。注意到在这个类里面也有和TestResult类似的匿名内部类。这种匿名内部类全是Protected接口的无名实现，这里的目的我认为有两点：
1) 由于内部类可以在接下来的情景中完全不可见，而且不被任何人使用，因此也隐藏了接口的实现细节。
2) 为了提高可重用性，而使用内部类比较快捷。这样不管你protect方法里面具体执行什么，对它错误、失败、异常捕捉的代码（TestResult中的runProtected方法）可以重用了。
这也正是为什么会出现上面那样奇怪的依赖关系：为了复用，要让runProtected方法放在一个TestCase和TestSetup都能调用的地方。
不过我认为为了复用而破坏了系统良好的结构和可读性，是需要仔细斟酌的。JUnit这样的设计估计是为了以后框架多次扩展后的重用考虑的。
说完了让我费解的问题。谈谈我觉得JUnit框架中让我感叹的地方，那是小小的框架里面使用了很多设计模式在里面。而这些模式的使用也正是为了体现出整个框架结构的简洁、可扩展。我将粗略的分析如下（模式应用的详细内容请关注我关于设计模式的文章）。先看看在junit.framework里面使用的设计模式。
命令模式：作为辅助单元测试的框架，开发人员在使用它的时候，应该仅仅关心测试用例的编写，JUnit只是一个测试用例的执行器和结果查看器，不应该关心太多关于这个框架的细节。而对于JUnit来说，它并不需要知道请求TestCase的操作信息，仅把它当作一种命令来执行，然后把执行测试结果发给开发人员。命令模式正是为了达到这种送耦合的目的。
组合模式：当系统的测试用例慢慢变得多起来，挨个运行测试用例成了一个棘手的问题。作为一个方便使用的单元测试框架，这一点是必须解决的。因此JUnit里面提供了TestSuite的功能，它允许将多个测试用例放到一个TestSuite里面来一次执行；而且要进一步的支持TestSuite里面套TestSuite的功能。使用组合模式能够很好的解决这个问题。
在上面我们已经提到了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的执行流程吧，这样你能对JUnit有个清晰的认识，虽然作为一个使用者这完全是不必要的。从《JUnit in Action》直接拿来一张JUnit流程图。
哦，也许你看晕了，我来当下导游好了。上面已经提到了TestRunner是BaseTestRunner的子类，在三个不同的ui包中各有一个TestRunner。这里我们仅以junit.textui包中的为例。
TestRunner作为入口程序是怎么被启动的呢？习惯了使用容器的我们现在也许很少考虑这个问题。那我们在TestRunner类里面找找吧，你看，你发现了这个：
public static void main(String args[])
这不是我们写小桌面程序时经常打交道的main方法么？对，这么简单。
