[转载]详细讲解在Spring中进行集成测试三（Spring提供的测试帮助类）

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

图 1 Spring测试工具类

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

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

java 代码

1. package com.baobaotao.test;
2. import org.springframework.test.ConditionalTestCase;
3. public class ConditionalTest1 extends ConditionalTestCase {
4. ①被忽略不执行的测试方法
5. private static String[] IGNORED_METHODS = {"testMethod1","testMethod3"};
7. @Override
8. protected boolean isDisabledInThisEnvironment(String testMethodName) {②所有在
9. for (String method : IGNORED_METHODS) { IGNORED_METHODS数组中
10. if (method.equals(testMethodName)) { 的方法都忽略执行。
11. return true;
12. }
13. } return false;
14. }
16. public void testMethod1(){ ③不执行
17. System.out.println("method1");
18. }
20. public void testMethod2(){ ④执行
21. System.out.println("method2");
22. }
24. public void testMethod3(){ ⑤不执行
25. System.out.println("method3");
26. }
27. }

如果我们直接承继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配置文件所在位置：

1. String[] getConfigLocations()：该方法允许你在指定Spring配置文件时使用资源类型前缀，这些资源类型前缀包括：classpath:、 file:。以类似于“com/baobaotao/beans.xml”形式指定的资源被当成类路径资源处理；
2. String[] getConfigPaths()：以“/”开头的地址被当成类路径处理，如“/com/baobaotao/beans.xml”，而未以“/”开头的 地址被当成相对于测试类所在包的文件路径，如“beans.xml”表示配置文件在测试类所在类包的目录下；
3. String getConfigPath()：和getConfigPaths()类似，在仅需指定一个配置文件中使用。

以上三个方法，它们的优先级和我们介绍的先后顺序对应，也就是说，当你在子类中覆盖了getConfigLocations()方法后，其它两个方法就没有意义了。所以你仅需选择三者当中适合的方法进行覆盖，而没有必要同时覆盖多个方法。
AbstractSingleSpringContextTests 将根据这些方法指定的Spring配置文件初始化Spring容器，然后将Spring容器引用添加到static缓存中。并通过 getApplicationContext()向子类开放ApplicationContext的引用。
一般情况下，所有的测试类 和测试方法都可以共享这个Spring容器直到测试完结，不过在某些极端情况下，测试方法可能会对Spring容器进行改动（比如通过程序改变Bean的 配置定义），如果这种改变对于其它测试方法来说是有干扰的，这就相当于“弄脏”了作为测试现场的Spring容器，因此在下一个测试方法执行前必须“抹 除”这个改变。你可以简单地在会“弄脏”Spring容器的测试方法中添加setDirty()方法向 AbstractSingleSpringContextTests报告这一行为，这样在下一个测试方法执行前， AbstractSingleSpringContextTests就会重新加载Spring容器以修补被“弄脏”的部分。
虽然你可 以直接继承AbstractSpringContextTests或AbstractSingleSpringContextTests创建自己的集成测 试用例，不过你大可不必如此着急。Spring已经提供了几个功能齐全、实践性更强的子类，让我们继续探索Spring集成测试工具类的精彩篇章吧。