一、引子
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添加出错记录
}
}
