详细讲解在Spring中进行集成测试AbstractDependencyInjectionSpringContextTests

http://www.51testing.com/html/06/n-64906-2.html

Spring提供的测试帮助类

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

图 1 Spring测试工具类

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

ConditionalTestCase

如果你直接通过扩展TestCase创建测试用例，则所有带test前缀的测试方法都会被毫无例外地执行。而ConditionalTestCase可以让你在某些情况下，有选择地关闭掉一些测试方法，不让他们在测试用例中执行。这给开发者带来了很大的灵活性，因为他们可以在某次测试中关闭掉一些测试方法，而仅运行当前特别关注的测试方法，将问题域聚集到一定范围内。
如果你要关闭某个测试方法行，仅需实现ConditionalTestCase的 isDisabledInThisEnvironment(String testMethodName)方法就可以了，ConditionalTestCase在运行每一个测试方法前会根据isDisabledInThisEnvironment()方法判断是简单放弃目标方法的运行，还是按正常方式执行之。该方法默认情况下对所有的测试方法都返回false，也即执行所有的测试方法。让我们来看一个具体例子：
代码清单 4 ConditionalTest1：有条件执行测试方法 package com.baobaotao.test;
import org.springframework.test.ConditionalTestCase;
public class ConditionalTest1 extends ConditionalTestCase {
①被忽略不执行的测试方法
private static String[] IGNORED_METHODS = {"testMethod1","testMethod3"};
@Override
protected boolean isDisabledInThisEnvironment(String testMethodName) {②所有在
for (String method : IGNORED_METHODS) { 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集成测试工具类的精彩篇章吧。

一般集成测试

应该说，Spring通过AbstractSpringContextTests或AbstractSingleSpringContextTests准备好了集成测试的一些基础设施，在建筑学上，这叫夯实地基，而AbstractDependencyInjectionSpringContextTests是在此地基之上建起的第一幢楼房。
AbstractDependencyInjectionSpringContextTests所新添的主要功能是其子类的属性能被Spring容器中的Bean自动装配，你无需手工通过 ApplicationContext#getBean()从容器中获取目标Bean自行装配。它很好回答了前面我们所指出第2)问题，下面我们通过实例进行学习：代码清单 5 DependencyInjectionCtxTest
package com.baobaotao.test;
import org.springframework.test.AbstractDependencyInjectionSpringContextTests;
import com.baobaotao.service.UserService;
public class DependencyInjectionCtxTest
extends AbstractDependencyInjectionSpringContextTests {
private UserService userService;
public void setUserService(UserService userService) {①该属性设置方法会被自动调动
this.userService = userService;
}
@Override
protected String[] getConfigLocations() { ②指定Spring配置文件所在位置
return new String[]{"baobaotao-service.xml","baobaotao-dao.xml"};
}
public void testHasMatchUser(){ ③测试方法
boolean match = userService.hasMatchUser("tom","123456");
assertEquals(true, match);
}
…
}

在②处，我们指定了Spring配置文件所在的位置，AbstractDependencyInjectionSpringContextTests将使用这些配置文件初始化好Spring容器，并将它们保存于static的缓存中。然后马上着手根据类型匹配机制（byType），自动将Spring容器中匹配测试类属性的Bean通过Setter注入到测试类中。为了方便说明这一重要的特性，我们先看一下baobaotao-service.xml的内容：

<beans>
<tx:annotation-driven/>
①按类型匹配于DependencyInjectionCtxTest的userService属性
<bean id="userService" class="com.baobaotao.service.UserServiceImpl">
<property name="userDao" ref="userDao"/>
<property name="loginLogDao" ref="loginLogDao"/>
</bean>
…
</beans>

根据baobaotao-service.xml配置文件的内容，我们知道Spring容器中有一个UserService Bean，AbstractDependencyInjectionSpringContextTests探测到Spring容器中存在一个匹配于userService属性的Bean后，就将其注入到DependencyInjectionCtxTest的userService属性中。userService是这个集成测试类的测试固件，因此我们说AbstractDependencyInjectionSpringContextTests可以自己装配测试固件。

解决自动装配问题

如果Spring容器中拥有多个匹配UserService类型的Bean，由于Spring没有足够的信息做出取舍决策，因此会抛出UnsatisfiedDependencyException异常。假设我们采用以下传统的事务管理的配置方式对UserService进行配置，按类型匹配的自动装配机制就会引发问题：
①用于被代理的目标Bean，按类型匹配于UserService <bean id="userServiceTarget" class="com.baobaotao.service.UserServiceImpl">
<property name="userDao" ref="userDao" />
<property name="loginLogDao" ref="loginLogDao"></property>
</bean>

②通过事务代理工厂为UserServiceImpl创建的代理Bean，也按匹配于UserService

由于①处和②处的Bean都按类型匹配于UserService，在对DependencyInjectionCtxTest的userService属性进行自动装配将会引发问题。有两种针对该问题的解决办法：

调整配置文件，使按类型匹配于UserService的Bean仅有一个，具体有以下两个方法：

将①处的Bean作为②处的内部Bean进行装配；

使用基于注解驱动的事务管理配置机制，这样就无需在配置文件中定义两个UserService的Bean了。关于注解驱动事务管理配置的详细信息，请参见9.6小节的内容。

改变DependencyInjectionCtxTest的自动装配机制：Spring默认使用byType类型的自动装配机制，但它允许你通过setAutowireMode()的方法改变默认自动装配的机制，比如你可以调用setAutowireMode(AUTOWIRE_BY_NAME)方法启用按名称匹配的自动装配机制。AbstractDependencyInjectionSpringContextTests定义了三个代表自动装配机制类型的常量，分别说明如下：
 AUTOWIRE_BY_TYPE：按类型匹配的方式进行自动装配，这个默认的机制；
 AUTOWIRE_BY_NAME：按名字匹配的方式进行自动装配
 AUTOWIRE_NO：不使用自动装配机制，这意味着你需要手工调用getBean()进行装配。

现在我们解决了在自动装配时，因Spring容器中存在多个匹配Bean而导致的问题，接下来让我们考察另一个自动装配的问题。

依赖检查

假设我们在DependencyInjectionCtxTest添加一个User类型的属性并提供Setter方法，而Spring容器中没有匹配该属性的Bean：

package com.baobaotao.test;
…
import com.baobaotao.domain.User;
public class DependencyInjectionCtxTest extends AbstractDependencyInjectionSpringContextTests {
private User user;
public void setUser(User user) {
this.user = user;
}
…
}

猜想一下重新运行DependencyInjectionCtxTest将会发生什么情况呢？答案可能让你失望：UnsatisfiedDependencyException再次象黑幕一样降临。在默认情况下， AbstractDependencyInjectionSpringContextTests要求所有属性都能在Spring容器中找到对应Bean，否则抛出异常。

仔细思考一下，这种运行机制并非没有道理，因为既然你已经提供了Setter方法，就相当于给出了这样的暗示信息：“这个属性测试类自身创建不了，必须由外部提供”。而在使用自动装配机制的情况下，测试类属性自动从Spring容器中注入匹配的属性，一般情况下不会手工去调用Setter方法准备属性。

如果你出于一些特殊的理由，希望在采用自动装配的情况下，如果有属性未得到装配也不在乎，那么你可以在测试类构造函数中调用setDependencyCheck(false)方法达到目的：

package com.baobaotao.test;
…
public class DependencyInjectionCtxTest extends AbstractDependencyInjectionSpringContextTests {
public DependencyInjectionCtxTest(){
setDependencyCheck(false); ①告知不进行属性依赖性检查
}
…
}

这个AbstractDependencyInjectionSpringContextTests就不会对测试类有些属性找不到匹配Bean而抛出异常了。

在不提供Setter方法的情况下自动注入

大多数IDE都提供了为属性变量自动生成Setter方法的操作，因此客观地说，为属性编写一个Setter方法的工作根本不值一提。如果你觉得众多的Setter方法影响了视觉感观，但又希望享受测试类属性自动装配的好处，Spring也不会让你失望的。你需要做的是以下两步的工作：
1) 将需要自动装配的属性变量声明为protected；
2) 在测试类构造函数中调用setPopulateProtectedVariables(true)方法。 package com.baobaotao.test;
…
public class DependencyInjectionCtxTest extends AbstractDependencyInjectionSpringContextTests {
protected UserService userService; ①将属性声明为protected
// public void setUserService(UserService userService) { ②大胆将Setter方法移除掉
// this.userService = userService;
// }
public DependencyInjectionCtxTest(){
setDependencyCheck(false);
setPopulateProtectedVariables(true); ③启用直接对属性变量进行注释的机制
}
…
}

将属性声明为protected后并通过setPopulateProtectedVariables(true)启用对属性变量直接注入的机制（启用反射机制注入），你就可以避免为属性变量编写对应的Setter方法了。

提示属性如果声明为public，虽然你也调用了setPopulateProtectedVariables(true)方法，属性变量依然不会被自动注入。所以这种机制仅限于protected的属性变量。

方便地恢复测试数据库现场

我们现在已经可以通过AbstractDependencyInjectionSpringContextTests的属性自动装配机制方便地建立起测试固件，省却手工调用getBean()自行准备测试固件的烦恼。当我们对UserService的hasMatchUser()和findUserByUserName()方法进行测试时，不会有任何问题，因为这两个方法仅对数据库执行读操作。但UserService以下两个接口方法会对数据库执行更改操作：

void loginSuccess(User user);
void registerUser(User user);

当我们对这两个接口方法进行测试时，它们将会在数据库中产生持久化数据。考虑对registerUser(User user)方法进行测试时，我们可能编写如下所示的测试方法：

public void testRegisterUser(){
User user = new User();
user.setUserId(2);
user.setUserName("john");
user.setPassword("123456");
userService.registerUser(user);
}

当第一次成功运行testRegisterUser()测试方法时，将在数据库中产生一条主键为2的记录，如何第二次重新运行testRegisterUser()测试方法其结果将不言自明：因主键冲突导致测试方法执行失败，最终报告测试用例没有通过。在这种情况下，测试用例未通过并不是因为UserServiceImpl#registerUser(User user)存在逻辑错误，而是因为测试方法的积累效应导致外在设施的现场发生变化而引起的问题。

为了防止这种问题，测试用例必须在保证不对数据库状态产生持久化变化的情况下，对目标类的数据操作逻辑正确性进行检测。乍一听这一要求有点貌似于“既想马儿跑，又想马儿不吃草”一样充满悖论，实则不然。只要我们让测试方法不提交事务，在测试完后自动回滚事务，就皆大欢喜了。

让测试方法自动拥有回滚能力

AbstractTransactionalSpringContextTests专为解决以上问题而生，也就是说前面我们所提及的第3)个问题在此得到了回答。只要继承该类创建测试用例，在默认情况下，测试方法中所包含的事务性数据操作都会在测试方法返回前被回滚。由于事务回滚操作发生在测试方法返回前的点上，所以你可以象往常一样在测试方法体中对数据操作的正确性进行校验。代码清单 6 UserServiceIntegrateTest：
package com.baobaotao.service;
import org.springframework.test.AbstractTransactionalSpringContextTests;
import com.baobaotao.domain.User;
public class UserServiceIntegrateTest extends AbstractTransactionalSpringContextTests {
private UserService userService;
public void setUserService(UserService userService) {
this.userService = userService;
}
@Override
protected String[] getConfigLocations() {
return new String[]{"baobaotao-service.xml", "baobaotao-dao.xml"};
}
public void testRegisterUser(){ ①测试方法中的数据操作将在方法返回前被回滚，不会对数据库
User user = new User(); 产生永久性数据操作，第二次运行该测试方法时，依旧可以
user.setUserId(2); 成功运行。
user.setUserName("john");
user.setPassword("123456");
userService.registerUser(user);
User user1 = userService.findUserByUserName("john"); ②对数据操作进行
assertEquals(user.getUserId(), user1.getUserId()); 正确性检验
}
}

如果testRegisterUser()是直接继承于AbstractDependencyInjectionSpringContextTests类的测试方法，则重复运行该测试方法就会发生数据冲突问题。但因为它位于继承于AbstractTransactionalSpringContextTests的测试用例类中，测试方法中对数据库的操作会被正确回滚，所以重复运行不会有任何问题。

如果你确实希望测试方法中对数据库的操作持久生效而不是被回滚，Spring也可以满足你的要求，你仅需要在测试方法中添加setComplete()方法就可以了。

public void testRegisterUser(){
…
User user1 = userService.findUserByUserName("john");
assertEquals(user.getUserId(), user1.getUserId());
setComplete(); ①测试方法中的事务性数据操作将被提交
}

AbstractTransactionalSpringContextTests还拥有几个可用于初始化测试数据库，并在测试完成后清除测试数据的方法，分别介绍如下：
 onSetUpBeforeTransaction()/onTearDownAfterTransaction()：子类可以覆盖这两个方法，以便在事务性测试方法运行的前后执行一些数据库初始化的操作并在事务完成后清除之；

 onSetUpInTransaction()/onTearDownInTransaction()：这对方法和前面介绍的方法完成相同的功能，只不过它们是在测试方法的相同事务中执行的。

AbstractTransactionalSpringContextTests另外还提供了一组用于测试延迟数据加载的方法：endTransaction()/startNewTransaction()。我在测试Hibernate、JPA等允许延迟数据加载的应用时，如何模拟数据在Service层事务中被部分加载，当传递到Web层时重新打开事务完成延迟部分数据加载的测试场景呢？这两个方法即为此用途而生：你可以在测试方法中显式调用endTransaction()方法以模拟从Service层中获取部分数据后返回，尔后，再通过startNewTransaction()开启一个和原事务无关新事务——模拟在Web层中重新打开事务，接下来你就可以访问延迟加载的数据，看是否一切如期所料了。

在代码清单 6的②处，我们通过UserService#findUserByUserName()方法对前面registerUser(user)方法数据操作的正确性进行检验。应该说，我们非常幸运，因为在UserService中刚好存在一个可用于检测registerUser(user)数据操作正确性的方法。让我们考虑另外的一种情况：要是 UserService不存在这样的方法，我们该如何检测registerUser(user)数据操作结果的正确性呢？显然我们不能使用肉眼观察的方法，那难道为了验证数据操作正确性专门编写一个配合性的数据访问类不成？

通过JDBC访问数据库，检测数据操作正确性

正当我们“山重水复疑无路”的时候，让我们再往前走上一程，柳暗花明将倏忽而至
——AbstractTransactionalDataSourceSpringContextTests就是花开景明之所。该类继承于AbstractTransactionalSpringContextTests，它添加了一个JdbcTemplate，你可以借由此道快意直达数据库。它自动使用Spring容器中的数据源（DataSource）创建好一个JdbcTemplate实例并开放给子类使用。值得注意的是，如果你采用byName自动装配机制，数据源Bean的名称必须取名为“dataSource”。

让我们对UserServiceIntegrateTest进行改造，以便让其自动拥有访问数据库的设施（JdbcTemplate），并用灵活的方法访问数据库进行数据操作的检验，其代码如下所示：

代码清单 7 UserServiceIntegrateWithJdbcTest
package com.baobaotao.service;
import org.springframework.test.AbstractTransactionalDataSourceSpringContextTests;
…
public class UserServiceIntegrateWithJdbcTest
extends AbstractTransactionalDataSourceSpringContextTests {①注意：继承类发生调整
private UserService userService;
public void setUserService(UserService userService) {
this.userService = userService;
}
@Override
protected String[] getConfigLocations() {
return new String[]{"baobaotao-service.xml", "baobaotao-dao.xml"};
}
public void testRegisterUser(){
User user = new User();
user.setUserId(2);
user.setUserName("john");
user.setPassword("123456");
userService.registerUser(user);
String sqlStr = " SELECT user_id FROM t_user WHERE user_name ='john' ";
int userId = jdbcTemplate.queryForInt(sqlStr); ①可以直接使用JdbcTemplate访问数据库了
assertEquals(user.getUserId(), userId);
setComplete();
}
}

jdbcTemplate是AbstractTransactionalDataSourceSpringContextTests类中定义的，子类可以直接使用它访问数据库。这样我们就可以灵活地访问数据库以检验目标测试方法的数据操作正确性。至此，我们终于毕其功于一役于AbstractTransactionalDataSourceSpringContextTests，顺利解决前面我们中指出的最后问题。

只要你通过扩展AbstractTransactionalSpringContextTests及其子类创建测试用例，所有测试方法都会工作了事务环境下。也就是说，即使某些测试方法不需要访问数据库，也会产生额外的事务管理开销，是否可以对测试方法启用事务管理的行为进行控制呢？此外，在一些情况下，除对目标方法逻辑运行的正确性进行检验外，我们还希望对目标方法的运行性能进行测试：如当目标方法运行时间超过200毫秒时，则测试用例视为未通过。诸如此类的问题，我们目前学习到的知识还不能很好的应付。Spring 2.0新增了注解驱动的测试工具为我们指明了道路，你仅需要通过简单为测试方法标注注解，我们刚才提出的“疑难”问题就可以迎刃而解了。

小结

本文我们讲述了使用Spring提供的一套测试工具对Spring应用程序进行集成测试所需的所有知识。
Spring建议你不应该在单元测试时使用到Spring容器，你应该在集成测试时才使用到Spring容器。手工创建测试固件或者手工装配测试固件的工作都是单调乏味没有创意的工作，通过使用Spring为集成测试提供了帮助类，你就可以享受测试固件自动装配的好处，将精力集中到目标类逻辑测试编写的工作上。

应该说大部分的Java应用都是Web应用，而大部分的Java Web应用都是数据库相关的应用，对数据库应用进行测试经常要考虑数据准备、数据库现场恢复、灵活访问数据以验证数据操作正确性等等的问题。这些问题如果没有一个很好的支持工具，将给编写测试用例造成挑战，幸好Spring都为我们搭建好满足这些需求的测试平台，你仅需要在此基础上编写特定的测试用例就可以了。

详细讲解在Spring中进行集成测试AbstractDependencyInjectionSpringContextTests相关推荐

赶紧进来修内功--- 详细讲解在内存中数据的存储方式(整形篇)
本文详细介绍了所有整形家族类型的取值范围;整形数据在内存中的存储方式(大小端存储方式)以及对应的解析,介绍讲解判断当前机器的存储方式代码练习题,掌握后编程基础更进一步牢固!!! 数据的存储一.整形数 ...
java 常量池和堆的关系_Java堆、栈和常量池以及相关String的详细讲解（经典中的经典）...
博客分类: Java综合一:在JAVA中,有六个不同的地方可以存储数据: 1. 寄存器(register). 这是最快的存储区,因为它位于不同于其他存储区的地方--处理器内部.但是寄存器的数量极其有 ...
linux用pwd转换到系统目录,详细讲解Linux系统中pwd命令的使用技巧
对于那些使用Linux命令行的人来说,'pwd'命令是非常有用的,它告诉你你现在在那个目录,从根目录(/)如何到达.特别是对于或许会在目录的切换间容易糊涂的Linux新手而言,'pwd' 可以拯救他们 ...
html标签详细讲解,HTML语法中的标签详细讲解1
对标签的总结: 头信息标签主体内容标签换行标签水平线标签居中对齐标签字体标签段落标签格式化标签引用标签 HTML注释语法字符控制标签标题文字标签 ~ 列表标签 . . table表 ...
java里throws详细讲解,基于Java中throw和throws的区别(详解)
系统自动抛出的异常所有系统定义的编译和运行异常都可以由系统自动抛出,称为标准异常,并且 Java 强烈地要求应用程序进行完整的异常处理,给用户友好的提示,或者修正后使程序继续执行. 语句抛出的异常 ...
Spring 事务管理的详细讲解及使用
文章目录一. Spring 事务管理简介二.Spring 事务管理器 1.Spring 事务管理接口 1.1. PlatformTransactionManager 接口 1.2. Transac ...
Spring中如何使用设计模式
2019独角兽企业重金招聘Python工程师标准>>> 关于设计模式,如果使用得当,将会使我们的代码更加简洁,并且更具扩展性.本文主要讲解Spring中如何使用策略模式,工厂方法模式 ...
spring 加载java类_在Spring中基于Java类进行配置的完整步骤
在Spring中基于Java类进行配置的完整步骤发布于 2020-7-7| 复制链接基于Java配置选项,可以编写大多数的Spring不用配置XML,下面前言JavaConfig 原来是 Spr ...
Spring中的@Value注解详解
本文主要介绍Spring @Value 注解注入属性值的使用方法的分析,文章通过示例代码非常详细地介绍,对于每个人的学习或工作都有一定的参考学习价值文章目录概述使用方式基于配置文件的注入基于 ...

详细讲解在Spring中进行集成测试AbstractDependencyInjectionSpringContextTests

详细讲解在Spring中进行集成测试AbstractDependencyInjectionSpringContextTests相关推荐

最新文章

热门文章