junit源码分析

通过对Junit的粗略了解，大致的知道了这里面的几种模式：
    junit源码与之spring、hibnate源码相比，就比较简单了，但是麻雀虽小，五脏俱全，这里面用到了几
    种设计模式，也是一个短小精悍、非常完所的一个框架。
    下面讲一个它的整体的框架吧：
     △ 先得到TestResult的对象，然后通过它的对象把TestListener的子类加到TestResult里面去。
     ** 观察者模式：TestResult 与众多测试结果监听器通过接口 TestListener 时行了松耦合，使它可以有
     不同的使用方式。TestResult不必关心有多少对象加到里面去，它只要根据列表通知所有观察者。
     因此，TestResult 不用更改自身代码，而轻易地完成了对TestListener这种监听器的无限扩充。
     
     △ 再通过Test来得到TestSuite对象，构造方法传了Class进去，然后对这个Class进行判断，看是不是Test
     的子类。如果不是就退出。是就会拿到这个类的全部方法，然后进行循环全部放到addTestMethod
     方法里面去。
     (然后把它的方法取出来，对该方法进行判断，看是不是以test开头、是不是公有的方法、
     里面有没有参数、返回类型是不是void类型。满足这些条件后再把该方法加到list里面去。)
   
     **  组合模式：当系统的测试用例慢慢变得多起来，挨个运行测试用例就成了一个棘手的问题。
     因此JUnit里面提供了TestSuite的功能，它将多个测试用例放到一个TestSuite里面来一次执行；
     而且是TestSuite里面套TestSuite的功能。很好的体现出了组合模式的树形结构。
    好处：
     1）它可以统一地处理组合结构TestSuite和单个对象TestCase，避免了条件判断
     2）很容易增加新的TestCase。
     
     △ 再执行Test的run方法把TestResult对象传进来，通过对Test的迭代，调用子类实现的方法，然后对
     TestListener进行操作，将里面监控的信息打印出来。如果当测试方法失败的时候会调用Assert类里
     的fail方法。然的把错误信息提示出来。
     **     命令模式：
     它并不需要知道请求TestCase的操作信息，仅把它当作一种命令来执行，然后把执行测试结果发给开发人员
     开发人员不需要关心关于这个框架的细节。命令模式正是为了达到这种送耦合的目的。
   
     **  模板模式：它在TestCase这个抽象类中将整个测试的流程设置好了，比如先执行Setup方法初始化
     测试前提，在运行测试方法，然后再TearDown来取消测试设置。而这些步骤的具体实现都延迟到子类中去，
     也就是你实现的测试类中。