详细讲解在spring中进行集成测试.docx

详细讲解在spring中进行集成测试.docx

《详细讲解在spring中进行集成测试.docx》由会员分享，可在线阅读，更多相关《详细讲解在spring中进行集成测试.docx（13页珍藏版）》请在冰豆网上搜索。

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

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

概述

在单元测试时，我们尽量在屏蔽模块间相互干扰的情况下，重点关注模块内部逻辑的正确性。

而集成测试则是在将模块整合在一起后进行的测试，它的目的在于发现一些模块间整合的问题。

有些功能很难通过模拟对象进行模拟，相反它们往往只能在真实模块整合后，才能真正运行起来，如事务管理就是其中比较典型的例子。

按照Spring的推荐（原话：

YoushouldnotnormallyusetheSpringcontainerforunittests:

simplypopulateyourPOJOsinplainJUnittests!

），在单元测试时，你不应该依赖于Spring容器。

换言之，你不应该在单元测试时启动ApplicatonContext并从中获取Bean，相反你应该通过模拟对象完成单元测试。

而集成测试的前提则是事先装配好模块和模块之间的关联类，如将DAO层真实的UserDao和LoginLogDao装配到UserServiceImpl再进行测试。

具体装配工作是在Spring配置文件中完成的，因此在一般情况下，集成测试需要启动Spring容器，你可以在测试类中简单地从Spring容器中取出目标Bean进行测试。

需要测试的业务接口

假设我们的应用中拥有一个UserService业务层接口，它拥有4个业务方法，其代码如下所示：

代码清单1UserServie接口

packagecom.baobaotao.service;

importcom.baobaotao.domain.User;

importorg.springframework.transaction.annotation.Transactional;

@Transactional

publicinterfaceUserService{

booleanhasMatchUser（StringuserName,Stringpassword）;

UserfindUserByUserName（StringuserName）;

voidloginSuccess（Useruser）;

voidregisterUser（Useruser）;

}

我们通过UserServiceImpl对UserService提供了实现：

代码清单2UserServiceImpl实现UserService接口

packagecom.baobaotao.service;

importcom.baobaotao.dao.LoginLogDao;

importcom.baobaotao.dao.UserDao;

importcom.baobaotao.domain.LoginLog;

importcom.baobaotao.domain.User;

publicclassUserServiceImplimplementsUserService{

privateUserDaouserDao;

privateLoginLogDaologinLogDao;

publicbooleanhasMatchUser（StringuserName,Stringpassword）{

intmatchCount=userDao.getMatchCount（userName,password）;

returnmatchCount>0;

}

publicUserfindUserByUserName（StringuserName）{

returnuserDao.findUserByUserName（userName）;

}

publicvoidloginSuccess（Useruser）{

user.setCredits（5+user.getCredits（））;

LoginLogloginLog=newLoginLog（）;

loginLog.setUserId（user.getUserId（））;

loginLog.setIp（user.getLastIp（））;

loginLog.setLoginDate（user.getLastVisit（））;

userDao.updateLoginInfo（user）;

loginLogDao.insertLoginLog（loginLog）;

}

publicvoidsetLoginLogDao（LoginLogDaologinLogDao）{

this.loginLogDao=loginLogDao;

}

publicvoidsetUserDao（UserDaouserDao）{

this.userDao=userDao;

}

}

UserServiceImpl引用了两个DAO层的类（UserDao和LoginLogDao）共同实现UserService的接口，在UserServiceImpl开放使用之前，我们有必须对其进行集成测试，以保证实现逻辑的正确性。

使用传统的方式进行集成测试

下面，我们通过传统的方式为UserServiceImpl编写了一个集成测试用例，测试代码如下所示：

代码清单3TestUserService：

UserService集成测试用例

packagecom.baobaotao.service;

…

publicclassTestUserServiceextendsTestCase{

publicApplicationContextctx=null;①Spring容器引用

privatestaticString[]CONFIG_FILES={②Spring配置文件

"baobaotao-dao.xml",

"baobaotao-service.xml"

};

protectedvoidsetUp（）throwsException{③启动Spring容器

ctx=newFileSystemXmlApplicationContext（CONFIG_FILES）;

}

publicvoidtestHasMatchUser（）{④测试方法一

④-1从容器中获取Bean

UserServiceuserService=（UserService）ctx.getBean（"userService"）;

booleanb1=userService.hasMatchUser（"admin","123456"）;

booleanb2=userService.hasMatchUser（"admin","1111"）;

assertTrue（b1）;

assertTrue（!

b2）;

}

publicvoidtestAddLoginLog（）{⑤测试方法二

⑤-1从容器中获取Bean

UserServiceuserService=（UserService）ctx.getBean（"userService"）;

Useruser=userService.findUserByUserName（"admin"）;

user.setUserId

（1）;

user.setUserName（"admin"）;

user.setLastIp（"192.168.12.7"）;

user.setLastVisit（newDate（））;

userService.loginSuccess（user）;

}

…//省略其余的测试方法

}

在这个测试用例中，我们使用了最原始的JUnit的TestCase进行集成测试，乍一看并没有多大的问题，但仔细分析一下，我们就可以总结出以下四点明显的不足：

1）导致多次Spring容器初始化问题：

根据JUnit测试方法的调用流程（参见错误！

未找到引用源。

小节的描述），每执行一个测试方法都会创建一个TestUserService实例并调用setUp（）方法。

由于我们在setUp（）方法中初始化Spring容器，这意味着TestUserService有多少个测试方法，Spring容器就会被重复初始化多少次。

虽然初始化Spring容器的速度并不会太慢，但由于可能会在Sprnig容器初始化时执行加载Hibernate映射文件等耗时的操作，如果每执行一个测试方法都必须重复初始化Spring容器，则对测试性能的影响是不容忽视的；

2）需要使用硬编码方式手工获取Bean：

在④-1和⑤-1处，我们通过ctx.getBean（）方法从Spring容器中获取需要测试的目标Bean，并且还要进行强制类型转换的造型操作。

这种乏味的操作迷漫在测试用例的代码中，让人觉得繁琐不堪；

3）数据库现场容易遭受破坏：

⑤处的测试方法会对数据库记录进行插入操作，虽然是针对开发数据库进行操作，但如果数据操作的影响是持久的，可能会影响到后面的测试行为。

举个例子，你在测试方法中插入一条ID为1的User记录，第一次运行不会有问题，第二次运行时，就会因为主键冲突而导致测试用例失败。

所以应该既能够完成功能逻辑检查，又能够在测试完成后恢复现场，不会留下“后遗症”；

4）没有对数据操作正确性进行检查：

⑤处我们向登录日志表插入了一条成功登录日志，可是我们却没有对t_login_log表中是否确实添加了一条记录进行检查。

原来我们的方式是打开数据库，肉眼观察是否插入了相应的记录，但这严重违背了自动测试的原则。

试想，你在测试包括成千上万个数据操作行为的程序时，如何用肉眼进行检查？

既然使用传统方式对Spring应用进行集成测试存在这么多不足，Spring责无旁贷地担当起革新之任。

它通过扩展JUnit框架提供了一套专门测试Spring应用的有力工具。

借助Spring集成测试工具的帮助，以上所罗列的种种问题将冰消雪融、云开雾散。

Spring提供的测试帮助类

Spring在org.springframework.test包中为测试提供了几个有用的类，它们都是JUnitTestCase的子类。

通过层层扩展，不断丰富测试的功能，我们可以通过下图了解这些类的继承关系：

图1Spring测试工具类

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

ConditionalTestCase

如果你直接通过扩展TestCase创建测试用例，则所有带test前缀的测试方法都会被毫无例外地执行。

而ConditionalTestCase可以让你在某些情况下，有选择地关闭掉一些测试方法，不让他们在测试用例中执行。

这给开发者带来了很大的灵活性，因为他们可以在某次测试中关闭掉一些测试方法，而仅运行当前特别关注的测试方法，将问题域聚集到一定范围内。

如果你要关闭某个测试方法行，仅需实现ConditionalTestCase的isDisabledInThisEnvironment（StringtestMethodName）方法就可以了，ConditionalTestCase在运行每一个测试方法前会根据isDisabledInThisEnvironment（）方法判断是简单放弃目标方法的运行，还是按正常方式执行之。

该方法默认情况下对所有的测试方法都返回false，也即执行所有的测试方法。

让我们来看一个具体例子：

代码清单4ConditionalTest1：

有条件执行测试方法

packagecom.baobaotao.test;

importorg.springframework.test.ConditionalTestCase;

publicclassConditionalTest1extendsConditionalTestCase{

①被忽略不执行的测试方法

privatestaticString[]IGNORED_METHODS={"testMethod1","testMethod3"};

@Override

protectedbooleanisDisabledInThisEnvironment（StringtestMethodName）{②所有在

for（Stringmethod:

IGNORED_METHODS）{IGNORED_METHODS数组中

if（method.equals（testMethodName））{的方法都忽略执行。

returntrue;

}

}

returnfalse;

}

publicvoidtestMethod1（）{③不执行

System.out.println（"method1"）;

}

publicvoidtestMethod2（）{④执行

System.out.println（"method2"）;

}

publicvoidtestMethod3（）{⑤不执行

System.out.println（"method3"）;

}

}

如果我们直接承继JUnit的TestCase，③、④及⑤处的三个测试方法都会被执行，但现在我们通过继承ConditionalTestCase编写测试类，并覆盖了isDisabledInThisEnvironment（）方法，当测试方法名位于IGNORED_METHODS数组中时，测试方法就被旁路掉了。

因此当运行ConditionalTest1时，你会发现只有④处的testMethod2（）测试方法得到了执行，其它两个测试方法看起来也被成功执行，只不过会程序日志会给出报告，告诉你哪些测试方法是真正被执行，而哪些方法被“伪执行”的。

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

AbstractSpringContextTests

AbstractSpringContextTests扩展于ConditionalTestCase，它维护了一个static类型的缓存器（HashMap），它使用键保存SpringApplicationContext实例，这意味着SpringApplicationContext是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”表示配置文件在测试类所在类包的目录下；

StringgetConfigPath（）：

和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）问题，下面我们通过实例进行学习：

代码清单5DependencyInjectionCtxTest

packagecom.baobaotao.test;

importorg.springframework.test.AbstractDependencyInjectionSpringContextTests;

importcom.baobaotao.service.UserService;

publicclassDependencyInjectionCtxTest

extendsAbstractDependencyInjectionSpringContextTests{

privateUserServiceuserService;

publicvoidsetUserService（UserServiceuserService）{①该属性设置方法会被自动调动

this.userService=userService;

}

@Override

protectedString[]getConfigLocations（）{②指定Spring配置文件所在位置

returnnewString[]{"baobaotao-service.xml","baobaotao-dao.xml"};

}

publicvoidtestHasMatchUser（）{③测试方法

booleanmatch=userService.hasMatchUser（"tom","123456"）;

assertEquals（true,match）;

}

…

}

在②处，我们指定了Spring配置文件所在的位置，AbstractDependencyInjectionSpringContextTests将使用这些配置文件初始化好Spring容器，并将它们保存于static的缓存中。

然后马上着手根据类型匹配机制（byType），自动将Spring容器中匹配测试类属性的Bean通过Setter注入到测试类中。

为了方便说明这一重要的特性，我们先看一下baobaotao-service.xml的内容：

annotation-driven/>

①按类型匹配于DependencyInjectionCtxTest的userService属性

…

根据baobaotao-service.xml配置文件的内容，我们知道Spring容器中有一个UserServiceBean，AbstractDependencyInjectionSpringContextTests探测到Spring容器中存在一个匹配于userService属性的Bean后，就将其注入到DependencyInjectionCtxTest的userService属性中。

userService是这个集成测试类的测试固件，因此我们说AbstractDependencyInjectionSpringContextTests可以自己装配测试固件。

解决自动装配问题

如果Spring容器中拥有多个匹配UserService类型的Bean，由于Spring没有足够的信息做出取舍决策，因此会抛出UnsatisfiedDependencyException异常。

假设我们采用以下传统的事务管理的配置方式对UserService进行配置，按类型匹配的自动装配机制就会引发问题：

①用于被代理的目标Bean，按类型匹配于UserService

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

class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">