JUnit的源码相比于spring和hibernate来说比较简单，但麻雀虽小，五脏俱全，其中用到了比较多的设计模式。很多人已经在网上分享了他们对JUnit源码解读心得，我这篇小文谈不出什么新意，本来不打算写，可近工作上暂时无事可做，那写写吧，结合《设计模式》来看看。
    我读的是JUnit3.0的源码，目前JUnit已经发布到4.0版本了，尽管有比较大的改进，但基本的骨架不变，读3.0是为了抓住重点，省去对旁支末节的关注。我们来看看JUnit的核心代码，也是Junit.framework包，除了4个辅助类（Assert，AssertFailedError，Protectable，TestFailure），剩下的是我们需要重点关注的了。我先展示一张UML类图：

    我们先不去关注TestDecorator类（此处是Decorator模式，下篇文章再讲），看看Test接口，以及它的两个实现类TestCase和TestSuite。很明显，此处用到了Command模式，为什么要使用这个模式呢？让我们先来看看什么是Command模式。

Command模式

Command模式是行为型模式之一

1.意图：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。
2.适用场景：
1）抽象出待执行的动作以参数化对象，Command模式是回调函数的面向对象版本。回调函数，我想大家都明白，函数在某处注册，然后在稍后的某个时候被调用。
2）可以在不同的时刻指定、排列和执行请求。
3）支持修改日志，当系统崩溃时，这些修改可以被重做一遍。
4）通过Command模式，你可以通过一个公共接口调用所有的事务，并且也易于添加新的事务。

3。UML图：