概述java
集成测试是在单元测试之上,一般是将一个或多个已进行过单元测试的组件组合起来完成的,即集成测试中通常不会出现Mock对象,都是实实在在的真实实现。web
对于单元测试,如前边在进行数据访问层单元测试时,经过Mock HibernateTemplate对象而后将其注入到相应的DAO实现,此时单元测试只测试某层的某个功能是否正确,对其余层如何提供服务采用Mock方式提供。spring
对于集成测试,如要进行数据访问层集成测试时,须要实实在在的HibernateTemplate对象而后将其注入到相应的DAO实现,此时集成测试将不只测试该层功能是否正确,还将测试服务提供者提供的服务是否正确执行。sql
使用Spring的一个好处是能很是简单的进行集成测试,无需依赖web服务器或应用服务器便可完成测试。Spring经过提供一套TestContext框架来简化集成测试,使用TestContext测试框架能得到许多好处,如Spring IoC容器缓存、事务管理、依赖注入、Spring测试支持类等等。数据库
Spring TestContext框架提供了一些通用的集成测试支持,主要提供以下支持:缓存
1、上下文管理及缓存:服务器
对于每个测试用例(测试类)应该只有一个上下文,而不是每一个测试方法都建立新的上下文,这样有助于减小启动容器的开销,提供测试效率。可经过以下方式指定要加载的上下文:app
@RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration( locations={"classpath:applicationContext-resources-test.xml", "classpath:cn/javass/point/dao/applicationContext-hibernate.xml"}) public class GoodsHibernateDaoIntegrationTest { }
locations:指定Spring配置文件位置;框架
inheritLocations:若是设置为false,将屏蔽掉父类中使用该注解指定的配置文件位置,默认为true表示继承父类中使用该注解指定的配置文件位置。ide
2、Test Fixture(测试固件)的依赖注入:
Test Fixture能够指运行测试时须要的任何东西,通常经过@Before定义的初始化Fixture方法准备这些资源,而经过@After定义的销毁Fixture方法销毁或还原这些资源。
Test Fixture的依赖注入就是使用Spring IoC容器的注入功能准备和销毁这些资源。可经过以下方式注入Test Fixture:
@Autowired private IGoodsDao goodsDao; @Autowired private ApplicationContext ctx;
便可以经过Spring提供的注解实现Bean的依赖注入来完成Test Fixture的依赖注入。
3、事务管理:
开启测试类的事务管理支持,即便用Spring 容器的事务管理功能,从而能够独立于应用服务器完成事务相关功能的测试。为了使测试中的事务管理起做用须要经过以下方式开启测试类事务的支持:
@RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration( locations={"classpath:applicationContext-resources-test.xml", "classpath:cn/javass/point/dao/applicationContext-hibernate.xml"}) @TransactionConfiguration( transactionManager = "txManager", defaultRollback=true) public class GoodsHibernateDaoIntegrationTest { }
Spring提供以下事务相关注解来支持事务管理:
@Transactional:使用@Transactional注解的类或方法将获得事务支持
transactionManager:指定事务管理器;
defaultRollback:是否回滚事务,默认为true表示回滚事务。
Spring还经过提供以下注解来简化事务测试:
@Transactional:使用@Transactional注解的类或方法表示须要事务支持;
@NotTransactional:只能注解方法,使用@NotTransactional注解的方法表示不须要事务支持,即不运行在事务中,Spring 3开始已不推荐使用;
@BeforeTransaction和@AfterTransaction:使用这两个注解注解的方法定义了在一个事务性测试方法以前或以后执行的行为,且被注解的方法将运行在该事务性方法的事务以外。
@Rollback(true):默认为true,用于替换@TransactionConfiguration中定义的defaultRollback指定的回滚行为。
4、经常使用注解支持:Spring框架提供以下注解来简化集成测试:
@DirtiesContext:表示每一个测试方法执行完毕需关闭当前上下文并重建一个全新的上下文,即不缓存上下文。可应用到类或方法级别,但在JUnit 3.8中只能应用到方法级别。
@ExpectedException:表示被注解的方法预期将抛出一个异常,使用如@ExpectedException(NotCodeException.class)来指定异常,定义方式相似于Junit 4中的@Test(expected = NotCodeException.class),@ExpectedException注解和@Test(expected =……)应该二者选一。
@Repeat :表示被注解的方法应被重复执行多少次,使用如@Repeat(2)方式指定。
@Timed:表示被注解的方法必须在多长时间内运行完毕,超时将抛出异常,使用如@Timed(millis=10)方式指定,单位为毫秒。注意此处指定的时间是以下方法执行时间之和:测试方法执行时间(或者任何测试方法重复执行时间之和)、@Before和@After注解的测试方法以前和以后执行的方法执行时间。而Junit 4中的@Test(timeout=2)指定的超时时间只是测试方法执行时间,不包括任何重复等。
5、TestContext框架支持类:提供对测试框架的支持,如Junit、TestNG测试框架,用于集成Spring TestContext和测试框架来简化测试,TestContext框架提供以下支持类:
JUnit 3.8支持类:提供对Spring TestContext框架与Junit3.8测试框架的集成:
AbstractJUnit38SpringContextTests:咱们的测试类继承该类后将获取到Test Fixture的依赖注入好处。
AbstractTransactionalJUnit38SpringContextTests:咱们的测试类继承该类后除了能获得Test Fixture的依赖注入好处,还额外获取到事务管理支持。
JUnit 4.5+支持类:提供对Spring TestContext框架与Junit4.5+测试框架的集成:
AbstractJUnit4SpringContextTests:咱们的测试类继承该类后将获取到Test Fixture的依赖注入好处。
AbstractTransactionalJUnit4SpringContextTests:咱们的测试类继承该类后除了能获得Test Fixture的依赖注入好处,还额外获取到事务管理支持。
定制 Junit4.5+运行器:经过定制本身的Junit4.5+运行器从而无需继承JUnit 4.5+支持类便可完成须要的功能,如Test Fixture的依赖注入、事务管理支持,
@RunWith(SpringJUnit4ClassRunner.class):使用该注解注解到测试类上表示将集成Spring TestContext和Junit 4.5+测试框架。
@TestExecutionListeners:该注解用于指定TestContext框架的监听器用于与TestContext框架管理器发布的测试执行事件进行交互,TestContext框架提供以下三个默认的监听器:DependencyInjectionTestExecutionListener、DirtiesContextTestExecutionListener、TransactionalTestExecutionListener分别完成对Test Fixture的依赖注入、@DirtiesContext支持和事务管理支持,即在默认状况下将自动注册这三个监听器,另外还可使用以下方式指定监听器:
@RunWith(SpringJUnit4ClassRunner.class) @TestExecutionListeners({}) public class GoodsHibernateDaoIntegrationTest { }
如上配置将经过定制的Junit4.5+运行器运行,但不会完成Test Fixture的依赖注入、事务管理等等,若是只须要Test Fixture的依赖注入,可使用@TestExecutionListeners({DependencyInjectionTestExecutionListener.class})指定。
在这里向你们推荐一个软件测试学习群:747981058
对于集成测试环境各类配置应该和开发环境或实际生产环境配置相分离,即集成测试时应该使用单独搭建一套独立的测试环境,不该使用开发环境或实际生产环境的配置,从而保证测试环境、开发、生产环境相分离。
一、拷贝一份Spring资源配置文件applicationContext-resources.xml,并命名为applicationContext-resources-test.xml表示用于集成测试使用,并修改以下内容:
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<value>classpath:resources-test.properties</value>
</list>
</property>
</bean>
2、拷贝一份替换配置元数据的资源文件(resources/resources.properties),并命名为resources-test.properties表示用于集成测试使用,并修改成如下内容:
db.driver.class=org.hsqldb.jdbcDriver
db.url=jdbc:hsqldb:mem:point_shop
db.username=sa
db.password=
#Hibernate属性
hibernate.dialect=org.hibernate.dialect.HSQLDialect
hibernate.hbm2ddl.auto=create-drop
hibernate.show_sql=false
hibernate.format_sql=true
jdbc:hsqldb:mem:point_shop:咱们在集成测试时将使用HSQLDB,并采用内存数据库模式运行;
hibernate.hbm2ddl.auto=create-drop:表示在建立SessionFactory时根据Hibernate映射配置建立相应Model的表结构,并在SessionFactory关闭时删除这些表结构。
到此咱们测试环境修改完毕,在进行集成测试时必定要保证测试环境、开发环境、实际生产环境相分离,即对于不一样的环境使用不一样的配置文件。
数据访问层集成测试,同单元测试同样目的不只测试该层定义的接口实现方法的行为是否正确,并且还要测试是否正确与数据库交互,是否发送并执行了正确的SQL,SQL执行成功后是否正确的组装了业务逻辑层须要的数据。
数据访问层集成测试再也不经过Mock对象与数据库交互的API来完成测试,而是使用实实在在存在的与数据库交互的对象来完成测试。
接下来让咱们学习一下如何进行数据访问层集成测试:
1、在test文件夹下建立以下测试类:
package cn.javass.point.dao.hibernate; //省略import @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration( locations={"classpath:applicationContext-resources-test.xml", "classpath:cn/javass/point/dao/applicationContext-hibernate.xml"}) @TransactionConfiguration(transactionManager = "txManager", defaultRollback=false) public class GoodsHibernateDaoIntegrationTest { @Autowired private ApplicationContext ctx; @Autowired private IGoodsCodeDao goodsCodeDao; }
@RunWith(SpringJUnit4ClassRunner.class):表示使用本身定制的Junit4.5+运行器来运行测试,即完成Spring TestContext框架与Junit集成;
@ContextConfiguration:指定要加载的Spring配置文件,此处注意咱们的Spring资源配置文件为“applicationContext-resources-test.xml”;
@TransactionConfiguration:开启测试类的事务管理支持配置,并指定事务管理器和默认回滚行为;
@Autowired:完成Test Fixture(测试固件)的依赖注入。
2、测试支持写完后,接下来测试一下分页查询全部已发布的商品是否知足需求:
@Transactional @Rollback @Test public void testListAllPublishedSuccess() { GoodsModel goods = new GoodsModel(); goods.setDeleted(false); goods.setDescription(""); goods.setName("测试商品"); goods.setPublished(true); goodsDao.save(goods); Assert.assertTrue(goodsDao.listAllPublished(1).size() == 1); Assert.assertTrue(goodsDao.listAllPublished(2).size() == 0); }
@Transactional:表示测试方法将容许在事务环境;
@Rollback:表示替换@ContextConfiguration指定的默认事务回滚行为,即将在测试方法执行完毕时回滚事务。
数据访问层的集成测试也是很是简单,与数据访问层的单元测试相似,也应该只对复杂的数据访问层代码进行测试。
业务逻辑层集成测试,目的一样是测试该层的业务逻辑是否正确,对于数据访问层实现经过Spring IoC容器完成装配,即便用真实的数据访问层实现来获取相应的底层数据。
接下来让咱们学习一下如何进行业务逻辑层集成测试:
1、在test文件夹下建立以下测试类:
@ContextConfiguration( locations={"classpath:applicationContext-resources-test.xml", "classpath:cn/javass/point/dao/applicationContext-hibernate.xml", "classpath:cn/javass/point/service/applicationContext-service.xml"}) @TransactionConfiguration(transactionManager = "txManager", defaultRollback=false) public class GoodsCodeServiceImplIntegrationTest extends AbstractJUnit4SpringContextTests { @Autowired private IGoodsCodeService goodsCodeService; @Autowired private IGoodsService goodsService; }
AbstractJUnit4SpringContextTests:表示将Spring TestContext框架与Junit4.5+测试框架集成;
@ContextConfiguration:指定要加载的Spring配置文件,此处注意咱们的Spring资源配置文件为“applicationContext-resources-test.xml”;
@TransactionConfiguration:开启测试类的事务管理支持配置,并指定事务管理器和默认回滚行为;
@Autowired:完成Test Fixture(测试固件)的依赖注入。
2、测试支持写完后,接下来测试一下购买商品Code码是否知足需求:
2.1、测试购买失败的场景:
@Transactional @Rollback @ExpectedException(NotCodeException.class) @Test public void testBuyFail() { goodsCodeService.buy("test", 1); }
因为咱们数据库中没有相应商品的Code码,所以将抛出NotCodeException异常。
2.2、测试购买成功的场景:
@Transactional @Rollback @Test public void testBuySuccess() { //1.添加商品 GoodsModel goods = new GoodsModel(); goods.setDeleted(false); goods.setDescription(""); goods.setName("测试商品"); goods.setPublished(true); goodsService.save(goods); //2.添加商品Code码 GoodsCodeModel goodsCode = new GoodsCodeModel(); goodsCode.setGoods(goods); goodsCode.setCode("test"); goodsCodeService.save(goodsCode); //3.测试购买商品Code码 GoodsCodeModel resultGoodsCode = goodsCodeService.buy("test", 1); Assert.assertEquals(goodsCode.getId(), resultGoodsCode.getId()); }
因为咱们添加了指定商品的Code码所以购买将成功,若是失败说明业务写错了,应该重写。
业务逻辑层的集成测试也是很是简单,与业务逻辑层的单元测试相似,也应该只对复杂的业务逻辑层代码进行测试。
对于表现层集成测试,一样相似于单元测试,但对于业务逻辑层都将使用真实的实现,而再也不是经过Mock对象来测试,这也是集成测试和单元测试的区别。
接下来让咱们学习一下如何进行表现层Action集成测试:
1、准备Struts提供的junit插件, 到struts-2.2.1.1.zip中拷贝以下jar包到类路径:
|
2、测试支持类:Struts2提供StrutsSpringTestCase测试支持类,咱们全部的Action测试类都须要继承该类;
三、准备Spring配置文件:因为咱们的测试类继承StrutsSpringTestCase且将经过覆盖该类的getContextLocations方法来指定Spring配置文件,但因为getContextLocations方法只能返回一个配置文件,所以咱们须要新建一个用于导入其余Spring配置文件的配置文件applicationContext-test.xml,具体内容以下:
<import resource="classpath:applicationContext-resources-test.xml"/> <import resource="classpath:cn/javass/point/dao/applicationContext-hibernate.xml"/> <import resource="classpath:cn/javass/point/service/applicationContext-service.xml"/> <import resource="classpath:cn/javass/point/web/pointShop-admin-servlet.xml"/> <import resource="classpath:cn/javass/point/web/pointShop-front-servlet.xml"/>
3.一、在test文件夹下建立以下测试类:
package cn.javass.point.web.front; //省略import @RunWith(SpringJUnit4ClassRunner.class) @TestExecutionListeners({}) public class GoodsActionIntegrationTest extends StrutsSpringTestCase { @Override protected String getContextLocations() { return "classpath:applicationContext-test.xml"; } @Before public void setUp() throws Exception { //1 指定Struts2配置文件 //该方式等价于经过web.xml中的<init-param>方式指定参数 Map<String, String> dispatcherInitParams = new HashMap<String, String>(); ReflectionTestUtils.setField(this, "dispatcherInitParams", dispatcherInitParams); //1.1 指定Struts配置文件位置 dispatcherInitParams.put("config", "struts-default.xml,struts-plugin.xml,struts.xml"); super.setUp(); } @After public void tearDown() throws Exception { super.tearDown(); } }
@RunWith(SpringJUnit4ClassRunner.class):表示使用本身定制的Junit4.5+运行器来运行测试,即完成Spring TestContext框架与Junit集成;
@TestExecutionListeners({}):没有指定任何监听器,即不会自动完成对Test Fixture的依赖注入、@DirtiesContext支持和事务管理支持;
StrutsSpringTestCase:集成测试Struts2+Spring时全部集成测试类必须继承该类;
setUp方法:在每一个测试方法以前都执行的初始化方法,其中dispatcherInitParams用于指定等价于在web.xml中的<init-param>方式指定的参数;必须调用super.setUp()用于初始化Struts2和Spring环境。
tearDown():在每一个测试方法以前都执行的销毁方法,必须调用super.tearDown()来销毁Spring容器等。
4、测试支持写完后,接下来测试一下前台购买商品Code码是否知足需求:
4.1、测试购买失败的场景:
@Test public void testBuyFail() throws UnsupportedEncodingException, ServletException { //2 前台购买商品失败 //2.1 首先重置hhtp相关对象,并准备准备请求参数 initServletMockObjects(); request.setParameter("goodsId", String.valueOf(Integer.MIN_VALUE)); //2.2 调用前台GoodsAction的buy方法完成购买相应商品的Code码 executeAction("/goods/buy.action"); GoodsAction frontGoodsAction = (GoodsAction) ActionContext.getContext().getActionInvocation().getAction(); //2.3 验证前台GoodsAction的buy方法有错误 Assert.assertTrue(frontGoodsAction.getActionErrors().size() > 0); }
initServletMockObjects():用于重置全部http相关对象,如request等;
request.setParameter("goodsId", String.valueOf(Integer.MIN_VALUE)):用于准备请求参数;
executeAction("/goods/buy.action"):经过模拟http请求来调用前台GoodsAction的buy方法完成商品购买
Assert.assertTrue(frontGoodsAction.getActionErrors().size() > 0):表示执行Action时有错误,即Action动做错误。若是条件不成立,说明咱们Action功能是错误的,须要修改。
4.2、测试购买成功的场景:
@Test public void testBuySuccess() throws UnsupportedEncodingException, ServletException { //3 后台新增商品 //3.1 准备请求参数 request.setParameter("goods.name", "测试商品"); request.setParameter("goods.description", "测试商品描述"); request.setParameter("goods.originalPoint", "1"); request.setParameter("goods.nowPoint", "2"); request.setParameter("goods.published", "true"); //3.2 调用后台GoodsAction的add方法完成新增 executeAction("/admin/goods/add.action"); //2.3 获取GoodsAction的goods属性 GoodsModel goods = (GoodsModel) findValueAfterExecute("goods"); //4 后台新增商品Code码 //4.1 首先重置hhtp相关对象,并准备准备请求参数 initServletMockObjects(); request.setParameter("goodsId", String.valueOf(goods.getId())); request.setParameter("codes", "a\rb"); //4.2 调用后台GoodsCodeAction的add方法完成新增商品Code码 executeAction("/admin/goodsCode/add.action"); //5 前台购买商品成功 //5.1 首先重置hhtp相关对象,并准备准备请求参数 initServletMockObjects(); request.setParameter("goodsId", String.valueOf(goods.getId())); //5.2 调用前台GoodsAction的buy方法完成购买相应商品的Code码 executeAction("/goods/buy.action"); GoodsAction frontGoodsAction = (GoodsAction) ActionContext.getContext().getActionInvocation().getAction(); //5.3 验证前台GoodsAction的buy方法没有错误 Assert.assertTrue(frontGoodsAction.getActionErrors().size() == 0); }
executeAction("/admin/goods/add.action"):调用后台GoodsAction的add方法,用于新增商品;
executeAction("/admin/goodsCode/add.action"):调用后台GoodCodeAction的add方法用于新增商品Code码;
executeAction("/goods/buy.action"):调用前台GoodsAction的buy方法,用于购买相应商品,其中Assert.assertTrue(frontGoodsAction.getActionErrors().size() == 0)表示购买成功,即Action动做正确。
表现层Action集成测试介绍就到此为止,如何深刻StrutsSpringTestCase来完成集成测试已超出本书范围,若是读者对这部分感兴趣能够到Struts2官网学习最新的测试技巧。
最后跟你们推荐一个测试学习群:747981058,里面大牛已经为咱们整理好了许多的学习资料,有自动化,接口,性能等等的学习资料!
人生是一个逆水行舟的过程,不进则退,我们一块儿加油吧!