junit3源码解析

1.框架背景

话说有一次Eric Gamma 坐飞机的时候偶遇Kent Beck(对，就是极限编程和TDD的发起人) ，  两位大牛（不认识他们的自行百度）见面寒暄过以后就觉得很无聊了。

旅途漫漫，干点啥好呢。

Kent Beck当时力推测试驱动开发,  但是没有一个工具或者框架能让大家轻松愉快的写测试，并且自动的运行测试。

两人勾兑了一下：不如自己挽起袖子写一个， 于是两人就在飞机上结对编程 ，  等到飞机的时候，一个划时代的单元测试工具就新鲜出炉了，这就是JUnit。

JUnit3.x版本是使用设计模式的典范， 抛去UI部分，只有两千多行代码，建议想学习源码的同学可以从junit3开始，你绝对值得拥有。

源码大家去这里下载：https://download.csdn.net/download/haoxin963/10623602

2.简单使用

junit的功能和使用应该不需要我介绍了吧，做java的如果没用过junit，那你走的路还很长。

下面是简单的常见一个TestCase的demo：

package junit.test;

import junit.framework.TestCase;

public class Jtest extends TestCase {
	

	public Jtest()
	{
		super();
	}
 
	public Jtest(String name)
	{
		super(name);
	}
	
	protected void setUp() throws Exception {
		super.setUp();
		System.out.println("setup of test");
	}
 
	protected void tearDown() throws Exception {
		super.tearDown();
		System.out.println("teardown of test");
	}
	
	public void  testTest() {
		assertEquals(1, 1);
		System.out.println("test");
	}
	
	public void  testTest1() {
		assertEquals(1, 1);
		System.out.println("test1");
	}
	
}

创建TestSuite的demo

package junit.test;

import junit.framework.Test;
import junit.framework.TestSuite;
import junit.textui.TestRunner;

public class JTestAll {
	public static void main(String[] args) {
		TestRunner.run(suite());
	}
	
	public static Test suite() {
		TestSuite suite = new TestSuite();
		suite.addTestSuite(Jtest.class);
		suite.addTestSuite(Jtest1.class);
		return suite;
	}
}

3.架构分析

打开源码文件，你会发现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 = TestResult

TestCase（测试用例）扩展了JUnit的TestCase类的类。它以testXXX方法是形式包含一个或多个测试。

TestSuite（测试集合）一组测试(多个TestCase组合在一起测试)。

TestRunner（测试运行器）实际上指的是任何继承BaseTestRunner的TestRunner的类。也就是说BaseTestRunner是所有TestRunner的超类。

UML图:

时序图：

 

先来看看各个类的职责。Assert类提供了JUnit使用的一整套的断言，这套断言都被TestCase继承下来，Assert也就变成了透明的。Test接口是为了统一TestCase和TestSuite的类型；而TestCase里面提供了运行单元测试类的方法；TestSuite构建用户自定义的测试集合。将一组方法整合在一起来测试，自定义组合。如果用户不定义suite方法来创建Testsuite，框架默认生成一个，包含所有的测试方法(TestCase)。TestResult故名思意就是提供存放测试结果的地方，但是在JUnit中它还带有一点控制器的功能。TestListener接口抽象了所有测试监听者的行为，他包括两个添加错误和失败的方法，开始测试和结束测试的方法。在JUnit框架中有两个类实现了这个接口，一个负责结果打印的ResultPrinter类，一个是所有TestRunner的基础类BaseTestRunner类（这两个类都不在framework包中）。

4.设计模式与源码解析

我觉得JUnit框架中最让我感叹的地方，那就是小小的框架里面使用了很多设计模式在里面。而这些模式的使用也正是为了体现出整个框架结构的简洁、可扩展。我将粗略的分析如下（模式应用的详细内容请关注我关于设计模式的文章）。先看看在junit.framework里面使用的设计模式。

1.模板方法模式

JUnit在TestCase这个抽象类中将整个测试的流程设置好了，比如先执行Setup方法初始化测试前提，在运行测试方法，然后再TearDown来取消测试设置。而这些步骤的具体实现都延迟到子类中去，也就是你实现的测试类中

TestCase抽象类里的两个方法：

	/**
	 * Sets up the fixture, for example, open a network connection.
	 * This method is called before a test is executed.
	 */
	protected void setUp() throws Exception {
	}
	/**
	 * Tears down the fixture, for example, close a network connection.
	 * This method is called after a test is executed.
	 */
	protected void tearDown() throws Exception {
	}

 子类重写这两个方法类实现测试前后需要做的动作

public class Jtest1 extends TestCase {
	protected void setUp() throws Exception {
		super.setUp();
		System.out.println("setup of test1");
	}
 
	protected void tearDown() throws Exception {
		super.tearDown();
		System.out.println("teardown of test1");
	}
	
	public void  testTest2() {
		assertEquals(1, 1);
		System.out.println("test2");
	}
	
	public void  testTest3() {
		assertEquals(2, 1);
		System.out.println("test3");
	}
}

2.组合模式

Junit中对于TestCase与TestSuite的设计很好的体现了组合模式，它允许将多个测试用例放到一个TestSuite里面来一次执行；而且要进一步的支持TestSuite里面套TestSuite的功能。TestSuite就像是根节点，TestClass就像是叶结点，他们都实现了Test接口，不同的类型有不同的run方法，有点类似于树的遍历，很好的体现出了组合模式的思路，对于问题的解耦比较有帮助，是简单元素与复杂元素都有同样的处理方法。

TestSuite类的构造方法：

	/**
	 * Constructs a TestSuite from the given class. Adds all the methods
	 * starting with "test" as test cases to the suite.
	 * Parts of this method was written at 2337 meters in the H黤fih黷te,
	 * Kanton Uri
	 */
	 public TestSuite(final Class theClass) {
		fName= theClass.getName();
		try {
			getTestConstructor(theClass); // Avoid generating multiple error messages
		} catch (NoSuchMethodException e) {
			addTest(warning("Class "+theClass.getName()+" has no public constructor TestCase(String name) or TestCase()"));
			return;
		}

		if (!Modifier.isPublic(theClass.getModifiers())) {
			addTest(warning("Class "+theClass.getName()+" is not public"));
			return;
		}

		Class superClass= theClass;
		Vector names= new Vector();
		while (Test.class.isAssignableFrom(superClass)) {
			Method[] methods= superClass.getDeclaredMethods();
			for (int i= 0; i < methods.length; i++) {
				addTestMethod(methods[i], names, theClass);
			}
			superClass= superClass.getSuperclass();
		}
		if (fTests.size() == 0)
			addTest(warning("No tests found in "+theClass.getName()));
	}

 

3.观察者模式

在Junit3.8中的监听器的使用就是一种典型的观察者模式，TessResult会在相关的操作执行完成之后回调Listerner的方法，同时Listener来进行对应的操作，TestResult中的fListestiners维护了一组监听器实例，每当固定阶段的任务执行完成时候就会告诉所有的监听器执行对应的操作，比如执行完测试部分输出信息：

TestResult：被观察者（主题）

TestListener：观察者

	
//注册观察者
public TestResult doRun(Test suite, boolean wait) {
		TestResult result= createTestResult();
		result.addListener(fPrinter);
		long startTime= System.currentTimeMillis();
		suite.run(result);
		long endTime= System.currentTimeMillis();
		long runTime= endTime-startTime;
		fPrinter.print(result, runTime);

		pause(wait);
		return result;
	}

	
//通知观察者
public synchronized void addFailure(Test test, AssertionFailedError t) {
		fFailures.addElement(new TestFailure(test, t));
		for (Enumeration e= cloneListeners().elements(); e.hasMoreElements(); ) {
			((TestListener)e.nextElement()).addFailure(test, t);
		}
	}

4.装饰者

为了拓展test的功能，比如重复测试等，这里使用的装饰者模式，增强了run的方法

public class RepeatedTest extends  TestDecorator {
	private int fTimesRepeat;

	public RepeatedTest(Test test, int repeat) {
		super(test);
		if (repeat < 0)
			throw new IllegalArgumentException("Repetition count must be > 0");
		fTimesRepeat= repeat;
	}
	public int countTestCases() {
		return super.countTestCases()*fTimesRepeat;
	}
	public void run(TestResult result) {
		for (int i= 0; i < fTimesRepeat; i++) {
			if (result.shouldStop())
				break;
			super.run(result);
		}
	}
	public String toString() {
		return super.toString()+"(repeated)";
	}
}

5.命令模式

作为辅助单元测试的框架，开发人员在使用它的时候，应该仅仅关心测试用例的编写，JUnit只是一个测试用例的执行器和结果查看器，不应该关心太多关于这个框架的细节。而对于JUnit来说，它并不需要知道请求TestCase的操作信息，仅把它当作一种命令来执行，然后把执行测试结果发给开发人员。命令模式正是为了达到这种送耦合的目的。

6.适配器模式

TestCase的源代码中：

	/**
	 * Runs the bare test sequence.
	 * @exception Throwable if any exception is thrown
	 */
	public void runBare() throws Throwable {
		setUp();
		try {
			runTest();
		}
		finally {
			tearDown();
		}
	}

runTest()中执行我们的测试方法：

	/**
	 * Override to run the test and assert its state.
	 * @exception Throwable if any exception is thrown
	 */
	protected void runTest() throws Throwable {
		assertNotNull(fName);
		Method runMethod= null;
		try {
			// use getMethod to get all public inherited
			// methods. getDeclaredMethods returns all
			// methods of this class but excludes the
			// inherited ones.
			runMethod= getClass().getMethod(fName, null);
		} catch (NoSuchMethodException e) {
			fail("Method \""+fName+"\" not found");
		}
		if (!Modifier.isPublic(runMethod.getModifiers())) {
			fail("Method \""+fName+"\" should be public");
		}

		try {
			runMethod.invoke(this, new Class[0]);
		}
		catch (InvocationTargetException e) {
			e.fillInStackTrace();
			throw e.getTargetException();
		}
		catch (IllegalAccessException e) {
			e.fillInStackTrace();
			throw e;
		}
	}

在runBare()方法中，通过runTest()方法将我们自己编写的testXXX()方法进行了适配，使得junit框架可以执行我们自己编写的TestCase；

runTest()方法中，首先获得我们自己编写的testXXX方法所对应的Method对象（无参），然后检查该Method对象所编写的方法是否是pulbic的，如果是则调用Method对象的invoke方法来执行我们自己编写的testXXX方法。

在这里目标接口Target和适配器Adapter变成了同一个类TestCase，而测试用例，作为Adaptee。

junit3中引入适配器模式的好处：

1）使用Adapter模式简化测试用例的开发，通过按照方法命名的规范来开发测试用例，不需要进行大量的类继承，提高代码的复用，减轻测试人员的工作量；

2）使用Adapter可以重新定义Adaptee的部分行为，如增强异常处理等

 

5.学习源码后感想

1.优美的抽象：TestCase + TestSuite + BaseTestRunner = TestResult

2.巧用设计模式使得框架易于使用和扩展

3.都是短小的方法，易于复用和阅读

4.好的命名比得上注释，比如使用模式的会放加模式名：TestDecorator