【第十三章】 测试 之 13.3 集成测试 ——跟我学spring3

13.3  集成测试

13.3.1  概述

      集成测试是在单元测试之上，通常是将一个或多个已进行过单元测试的组件组合起来完成的，即集成测试中一般不会出现Mock对象，都是实实在在的真实实现。

      对于单元测试，如前边在进行数据访问层单元测试时，通过Mock HibernateTemplate对象然后将其注入到相应的DAO实现，此时单元测试只测试某层的某个功能是否正确，对其他层如何提供服务采用Mock方式提供。

      对于集成测试，如要进行数据访问层集成测试时，需要实实在在的HibernateTemplate对象然后将其注入到相应的DAO实现，此时集成测试将不仅测试该层功能是否正确，还将测试服务提供者提供的服务是否正确执行。

      使用Spring的一个好处是能非常简单的进行集成测试，无需依赖web服务器或应用服务器即可完成测试。Spring通过提供一套TestContext框架来简化集成测试，使用TestContext测试框架能获得许多好处，如Spring IoC容器缓存、事务管理、依赖注入、Spring测试支持类等等。

13.3.2 Spring TestContext框架支持

Spring TestContext框架提供了一些通用的集成测试支持，主要提供如下支持：

一、上下文管理及缓存：

对于每一个测试用例（测试类）应该只有一个上下文，而不是每个测试方法都创建新的上下文，这样有助于减少启动容器的开销，提供测试效率。可通过如下方式指定要加载的上下文：

• locations：指定Spring配置文件位置；

• inheritLocations：如果设置为false，将屏蔽掉父类中使用该注解指定的配置文件位置，默认为true表示继承父类中使用该注解指定的配置文件位置。

二、Test Fixture（测试固件）的依赖注入：

Test Fixture可以指运行测试时需要的任何东西，一般通过@Before定义的初始化Fixture方法准备这些资源，而通过@After定义的销毁Fixture方法销毁或还原这些资源。

Test Fixture的依赖注入就是使用Spring IoC容器的注入功能准备和销毁这些资源。可通过如下方式注入Test Fixture：

即可以通过Spring提供的注解实现Bean的依赖注入来完成Test Fixture的依赖注入。

三、事务管理：

开启测试类的事务管理支持，即使用Spring 容器的事务管理功能，从而可以独立于应用服务器完成事务相关功能的测试。为了使测试中的事务管理起作用需要通过如下方式开启测试类事务的支持：

Spring提供如下事务相关注解来支持事务管理：

• @Transactional：使用@Transactional注解的类或方法将得到事务支持

• transactionManager:指定事务管理器；

• defaultRollback：是否回滚事务，默认为true表示回滚事务。

Spring还通过提供如下注解来简化事务测试：

• @Transactional：使用@Transactional注解的类或方法表示需要事务支持；

• @NotTransactional：只能注解方法，使用@NotTransactional注解的方法表示不需要事务支持，即不运行在事务中，Spring 3开始已不推荐使用；

• @BeforeTransaction和@AfterTransaction：使用这两个注解注解的方法定义了在一个事务性测试方法之前或之后执行的行为，且被注解的方法将运行在该事务性方法的事务之外。

• @Rollback(true)：默认为true，用于替换@TransactionConfiguration中定义的defaultRollback指定的回滚行为。

四、常用注解支持：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)指定的超时时间只是测试方法执行时间，不包括任何重复等。

• 除了支持如上注解外，还支持【第十二章 零配置】中依赖注入等注解。

五、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支持和事务管理支持，即在默认情况下将自动注册这三个监听器，另外还可以使用如下方式指定监听器：

    如上配置将通过定制的Junit4.5+运行器运行，但不会完成Test Fixture的依赖注入、事务管理等等，如果只需要Test Fixture的依赖注入，可以使用@TestExecutionListeners({DependencyInjectionTestExecutionListener.class})指定。

• TestNG支持类：提供对Spring TestContext框架与TestNG测试框架的集成：

        AbstractTestNGSpringContextTests：我们的测试类继承该类后将获取到Test Fixture的依赖注入好处。

        AbstractTransactionalTestNGSpringContextTests：我们的测试类继承该类后除了能得到Test Fixture的依赖注入好处，还额外获取到事务管理支持。

到此Spring TestContext测试框架减少完毕了，接下来让我们学习一下如何进行集成测试吧。

13.3.3        准备集成测试环境

对于集成测试环境各种配置应该和开发环境或实际生产环境配置相分离，即集成测试时应该使用单独搭建一套独立的测试环境，不应使用开发环境或实际生产环境的配置，从而保证测试环境、开发、生产环境相分离。

1、拷贝一份Spring资源配置文件applicationContext-resources.xml，并命名为applicationContext-resources-test.xml表示用于集成测试使用，并修改如下内容：

2、拷贝一份替换配置元数据的资源文件（resources/resources.properties），并命名为resources-test.properties表示用于集成测试使用，并修改为以下内容：

• jdbc:hsqldb:mem:point_shop：我们在集成测试时将使用HSQLDB，并采用内存数据库模式运行；

• hibernate.hbm2ddl.auto=create-drop：表示在创建SessionFactory时根据Hibernate映射配置创建相应Model的表结构，并在SessionFactory关闭时删除这些表结构。

到此我们测试环境修改完毕，在进行集成测试时一定要保证测试环境、开发环境、实际生产环境相分离，即对于不同的环境使用不同的配置文件。

13.3.4  数据访问层

      数据访问层集成测试，同单元测试一样目的不仅测试该层定义的接口实现方法的行为是否正确，而且还要测试是否正确与数据库交互，是否发送并执行了正确的SQL，SQL执行成功后是否正确的组装了业务逻辑层需要的数据。

      数据访问层集成测试不再通过Mock对象与数据库交互的API来完成测试，而是使用实实在在存在的与数据库交互的对象来完成测试。

接下来让我们学习一下如何进行数据访问层集成测试：

1、在test文件夹下创建如下测试类：

• @RunWith(SpringJUnit4ClassRunner.class)：表示使用自己定制的Junit4.5+运行器来运行测试，即完成Spring TestContext框架与Junit集成；

• @ContextConfiguration：指定要加载的Spring配置文件，此处注意我们的Spring资源配置文件为“applicationContext-resources-test.xml”；

• @TransactionConfiguration：开启测试类的事务管理支持配置，并指定事务管理器和默认回滚行为；

• @Autowired：完成Test Fixture（测试固件）的依赖注入。

2、测试支持写完后，接下来测试一下分页查询所有已发布的商品是否满足需求：

• @Transactional：表示测试方法将允许在事务环境；

• @Rollback：表示替换@ContextConfiguration指定的默认事务回滚行为，即将在测试方法执行完毕时回滚事务。

数据访问层的集成测试也是非常简单，与数据访问层的单元测试类似，也应该只对复杂的数据访问层代码进行测试。

13.3.5  业务逻辑层

业务逻辑层集成测试，目的同样是测试该层的业务逻辑是否正确，对于数据访问层实现通过Spring IoC容器完成装配，即使用真实的数据访问层实现来获取相应的底层数据。

接下来让我们学习一下如何进行业务逻辑层集成测试：

1、在test文件夹下创建如下测试类：

• AbstractJUnit4SpringContextTests：表示将Spring TestContext框架与Junit4.5+测试框架集成；

• @ContextConfiguration：指定要加载的Spring配置文件，此处注意我们的Spring资源配置文件为“applicationContext-resources-test.xml”；

• @TransactionConfiguration：开启测试类的事务管理支持配置，并指定事务管理器和默认回滚行为；

• @Autowired：完成Test Fixture（测试固件）的依赖注入。

2、测试支持写完后，接下来测试一下购买商品Code码是否满足需求：

2.1、测试购买失败的场景：

由于我们数据库中没有相应商品的Code码，因此将抛出NotCodeException异常。

2.2、测试购买成功的场景:

由于我们添加了指定商品的Code码因此购买将成功，如果失败说明业务写错了，应该重写。

业务逻辑层的集成测试也是非常简单，与业务逻辑层的单元测试类似，也应该只对复杂的业务逻辑层代码进行测试。

13.3.5  表现层

对于表现层集成测试，同样类似于单元测试，但对于业务逻辑层都将使用真实的实现，而不再是通过Mock对象来测试，这也是集成测试和单元测试的区别。

接下来让我们学习一下如何进行表现层Action集成测试：

1、准备Struts提供的junit插件, 到struts-2.2.1.1.zip中拷贝如下jar包到类路径：

lib\struts2-junit-plugin-2.2.1.1.jar

2、测试支持类：Struts2提供StrutsSpringTestCase测试支持类，我们所有的Action测试类都需要继承该类；

3、准备Spring配置文件：由于我们的测试类继承StrutsSpringTestCase且将通过覆盖该类的getContextLocations方法来指定Spring配置文件，但由于getContextLocations方法只能返回一个配置文件，因此我们需要新建一个用于导入其他Spring配置文件的配置文件applicationContext-test.xml，具体内容如下：

3、在test文件夹下创建如下测试类：

• @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、测试购买失败的场景：

• 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、测试购买成功的场景:

• 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官网学习最新的测试技巧。

本文链接：领悟书生教程网，转自http://sishuok.com/forum/blogPost/list/0/2557.html