一、引子
JUnit源码是我仔细阅读过的第一个开源项目源码。阅读高手写的代码能学到一些好的编程风格和实现思路，这是提高自己编程水平行之有效的方法，因此早就想看看这些赫赫有名的框架是怎么回事了。今天就拿最简单的JUnit下手，也算开始自己的源码分析之路。
JUnit作为最著名的单元测试框架，由两位业界有名人士协力完成，已经经历了多次版本升级（了解JUnit基础、JUnit实践）。JUnit总体来说短小而精悍，有不少值得我们借鉴的经验在里面；但是也有一些不足存在，当然这对于任何程序来说都是难免的。
下面我们将从整体（宏观）和细节（微观）两方面来分析JUnit源码，以下分析基于3.8.1版。
二、宏观——架构与模式
打开源码文件，你会发现JUnit源码被分配到6个包中：junit.awtui、junit.swingui、junit.textui、junit.extensions、junit.framework、junit.runner。其中前三个包中包含了JUnit运行时的入口程序以及运行结果显示界面，它们对于JUnit使用者来说基本是透明的。junit.runner包中包含了支持单元测试运行的一些基础类以及自己的类加载器，它对于JUnit使用者来说是完全透明的。
剩下的两个包是和使用JUnit进行单元测试紧密联系在一起的。其中junit.framework包含有编写一般JUnit单元测试类必须是用到的JUnit类；而junit.extensions则是对framework包在功能上的一些必要扩展以及为更多的功能扩展留下的接口。
JUnit提倡单元测试的简单化和自动化。这就要求JUnit的使用要简单化，而且要很容易的实现自动化测试。整个JUnit的设计大概也是遵循这个前提吧。整个框架的骨干仅有三个类组成（下图所示）。
如果你掌握了TestCase、TestSuite、BaseTestRunner的工作方式，那么你就可以随心所欲的编写测试代码了。
下面我们来看看junit.framework中类之间的关系，下图是我根据源代码分析出来的，大部分关系都表示了出来。
先来看看各个类的职责。Assert类提供了JUnit使用的一整套的断言，这套断言都被TestCase继承下来，Assert也就变成了透明的。Test接口是为了统一TestCase和TestSuite的类型；而TestCase里面提供了运行单元测试类的方法；在TestSuite中则提供了加载单元测试类，检验测试类格式等等的方法。TestResult故名思意就是提供存放测试结果的地方，但是在JUnit中它还带有一点控制器的功能。
在这里指出其中我认为有些不妥的地方。图上TestCase和TestResult之间是双向的依赖关系，而在UML类图的关系中指出：依赖关系总是单向的。就让我们来看看这这个可疑的地方。
TestCase中的代码：
/**
* Runs the test case and collects the results in TestResult.
*/
public void run(TestResult result) {
//调用了result中的run方法，
//TestResult按照名称来看应该是一个记录测试结果的类，怎么还能run？
result.run(this);
}
相应得TestResult中的代码：
/**
* Runs a TestCase.
*/
protected void run(final TestCase test) {
//开始测试
startTest(test);
//这个匿名内类的使用一会再讲
Protectable p= new Protectable() {
public void protect() throws Throwable {
//天那，这里又调用了TestCase里面的runBare方法
test.runBare();
}
};
runProtected(test, p); //这个方法就是要执行上面制定的匿名内类
endTest(test);
}
TestResult中runProtected方法：
public void runProtected(final Test test, Protectable p) {
try {
p.protect();
}
catch (AssertionFailedError e) {
addFailure(test, e); //给TestResult添加失败记录
}
catch (ThreadDeath e) { // don't catch ThreadDeath by accident
throw e;
}
catch (Throwable e) {
addError(test, e); //给TestResult添加出错记录
}
}
为什么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的功能。使用组合模式能够很好的解决这个问题。
