Spring提供的测试帮助类

Spring在org.springframework.test包中为测试提供了几个有用的类，它们都是JUnit TestCase的子类。通过层层扩展，不断丰富测试的功能，我们可以通过下图了解这些类的继承关系：

 

 

 

下面，我们来逐个了解这棵承继类树中每个节点测试类的功用，第一个要认识的是直接扩展于TestCase的ConditionalTestCase测试类。
ConditionalTestCase

如果你直接通过扩展TestCase创建测试用例，则所有带test前缀的测试方法都会被毫无例外地执行。而ConditionalTestCase可以让你在某些情况下，有选择地关闭掉一些测试方法，不让他们在测试用例中执行。这给开发者带来了很大的灵活性，因为他们可以在某次测试中关闭掉一些测试方法，而仅运行当前特别关注的测试方法，将问题域聚集到一定范围内。
如果你要关闭某个测试方法行，仅需实现ConditionalTestCase 的 isDisabledInThisEnvironment(String testMethodName)方法就可以了，ConditionalTestCase在运行每一个测试方法前会根据 isDisabledInThisEnvironment()方法判断是简单放弃目标方法的运行，还是按正常方式执行之。该方法默认情况下对所有的测试方法都返回false，也即执行所有的测试方法。让我们来看一个具体例子：
代码清单 4 ConditionalTest1：有条件执行测试方法

package com.test; import org.springframework.test.ConditionalTestCase; public class ConditionalTest1 extends ConditionalTestCase { //①被忽略不执行的测试方法 private static String[] IGNORED_METHODS = {"testMethod1","testMethod3"}; @Override protected boolean isDisabledInThisEnvironment(String testMethodName) { // ②所有在IGNORED_METHODS数组中的方法都忽略执行。 for (String method : IGNORED_METHODS) { if (method.equals(testMethodName)) { return true; } } return false; } public void testMethod1(){// ③不执行 System.out.println("method1"); } public void testMethod2(){// ④执行 System.out.println("method2"); } public void testMethod3(){// ⑤不执行 System.out.println("method3"); } }

 

 

如果我们直接承继JUnit的TestCase，③、④及⑤处的三个测试方法都会被执行，但现在我们通过继承 ConditionalTestCase编写测试类，并覆盖了isDisabledInThisEnvironment()方法，当测试方法名位于 IGNORED_METHODS数组中时，测试方法就被旁路掉了。因此当运行ConditionalTest1时，你会发现只有④处的 testMethod2()测试方法得到了执行，其它两个测试方法看起来也被成功执行，只不过会程序日志会给出报告，告诉你哪些测试方法是真正被执行，而哪些方法被“伪执行”的。

ConditionalTestCase其实可用于任何程序的单元测试中，它本身并没有和Spring容器有任何关联，它仅添加了一个按条件执行测试方法的功能。

AbstractSpringContextTests

AbstractSpringContextTests 扩展于ConditionalTestCase，它维护了一个static类型的缓存器（HashMap），它使用键保存Spring ApplicationContext实例，这意味着Spring ApplicationContext是JVM级的，不同测试用例、不同测试方法都可以共享这个实例。也就是说，在运行多个测试用例和测试方法时，Spring容器仅需要实例化一次就可以了，极大地提高了基于Spring容器测试程序的运行效率。Spring通过这个测试帮助类解决了前面我们所指出的第1)个问题。

AbstractSingleSpringContextTests

AbstractSingleSpringContextTests继承于AbstractSpringContextTests，它通过一些方法让你方便地指定Spring配置文件所在位置：

? String[] getConfigLocations()：该方法允许你在指定Spring配置文件时使用资源类型前缀，这些资源类型前缀包括：classpath:、 file:。以类似于“com/baobaotao/beans.xml”形式指定的资源被当成类路径资源处理；

? String[] getConfigPaths()：以“/”开头的地址被当成类路径处理，如“/com/baobaotao/beans.xml”，而未以“/”开头的地址被当成相对于测试类所在包的文件路径，如“beans.xml”表示配置文件在测试类所在类包的目录下；
? String getConfigPath()：和getConfigPaths()类似，在仅需指定一个配置文件中使用。

以上三个方法，它们的优先级和我们介绍的先后顺序对应，也就是说，当你在子类中覆盖了getConfigLocations()方法后，其它两个方法就没有意义了。所以你仅需选择三者当中适合的方法进行覆盖，而没有必要同时覆盖多个方法。

AbstractSingleSpringContextTests 将根据这些方法指定的Spring配置文件初始化Spring容器，然后将Spring容器引用添加到static缓存中。并通过 getApplicationContext()向子类开放ApplicationContext的引用。

一般情况下，所有的测试类和测试方法都可以共享这个Spring容器直到测试完结，不过在某些极端情况下，测试方法可能会对Spring容器进行改动（比如通过程序改变Bean的配置定义），如果这种改变对于其它测试方法来说是有干扰的，这就相当于“弄脏”了作为测试现场的Spring容器，因此在下一个测试方法执行前必须“抹除 ”这个改变。你可以简单地在会“弄脏”Spring容器的测试方法中添加setDirty()方法向 AbstractSingleSpringContextTests报告这一行为，这样在下一个测试方法执行前，AbstractSingleSpringContextTests就会重新加载Spring容器以修补被“弄脏”的部分。

虽然你可以直接继承AbstractSpringContextTests或AbstractSingleSpringContextTests创建自己的集成测试用例，不过你大可不必如此着急。Spring已经提供了几个功能齐全、实践性更强的子类，让我们继续探索Spring集成测试工具类的精彩篇章吧。