IDC资讯中心
一、引子
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) { // dont 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的功能。使用组合模式能够很好的解决这个问题。
