Junit

转自http://blog.csdn.net/ai92/archive/2005/03/12/318318.aspx JUnit源码分析（一） 收藏 一、引子 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中它还带有一点控制器的功能。TestListener接口抽象了所有测试监听者的行为，他包括两个添加错误和失败的方法，开始测试和结束测试的方法。在JUnit框架中有两个类实现了这个接口，一个负责结果打印的ResultPrinter类，一个是所有TestRunner的基础类BaseTestRunner类（这两个类都不在framework包中）。 在这里指出其中我认为有些不妥的地方。图上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的功能。使用组合模式能够很好的解决这个问题。 模板模式：JUnit在TestCase这个抽象类中将整个测试的流程设置好了，比如先执行Setup方法初始化测试前提，在运行测试方法，然后再TearDown来取消测试设置。而这些步骤的具体实现都延迟到子类中去，也就是你实现的测试类中。 模板模式：JUnit在TestCase这个抽象类中将整个测试的流程设置好了，比如先执行Setup方法初始化测试前提，在运行测试方法，然后再TearDown来取消测试设置。而这些步骤的具体实现都延迟到子类中去，也就是你实现的测试类中。