Junit---Introduce a Base Test Case

问题：
  如果有一个通用方法的集合并且希望在测试中尽可能多的使用它。在这种情况下，将这些方法作为一个测试用例类的一部分来使用比较好，而不是作为其他某个类中类一级的方法。

背景：
    经常需要为Junit测试建立一个逐步扩充的可重用的工具方法库，可能最常见的一类可重用方法就是用户自定义的断言了。如果经常使用某种断言，并且每次使用这种断言的时候都希望看到相同的失败信息，那我们建议你将底层的测试条件和失败信息封装到一个新的断言方法里去。这个新方法的名字可以用assert开头，这样有助于判断其类型为断言，无论谁使用这个方法都会立刻猜到这可能会引起一个断言失败。

这里本来想给出一个例子，但是想想还是不给出源码。如果想要知道源码的话，你看看Selenium里面用一个SeleniumEquals的断言。有兴趣可以将它找出来看看。

技巧：
     引入一个基本测试用例--- 一个可以作为所有测试用例类的超类的类。通常我们管这个类叫做BaseTestCase，如果你已经有了一些测试，只要简单地修改它们使其继承这个新类就可以了。即使刚开始的时候BaseTestCase中什么方法都没有，使用这样一个基本测试用例类来建立项目可以很自然地引导程序员将他们认为在测试用例中会用到的任何工具方法方法哦这里面。
   如果BeasTestCase中的一个方法实际上是不需要的，那么将其"下放"到相关的测试用例类中是没有什么问题的。同样地，根据需要将任何常见的方法“提升”到BaseTestCase中也是很容易的，因为所有的测试用例类都是从它继承来的。

讨论：
   测试驱动开发的纯化论者在读过Junit测试可能会说："你不需要这么做"简而言之，他们争辩的是一个BaseTestCase类应该是根据设计的需要自然产生的，而不是强迫一个项目从一开始就使用它。我们也由衷赞同这个YANGI原则(You Arent Gonna Need It缩写)，并且相信本技巧不会破坏此原则，BaseTestCase类迟早是要用到的。

在重构测试代码的教程中----特别是重构客户测试或端到端测试时---我们会例行公事般地加上两种常用的基本方法--------用户自定义的断言和对测试框架的扩展。不管用的是JUnit、DBUnit、HttpUnit、HtmlUnit或者是其他的测试框架，我们都会这样做的。