人在江湖

轉(zhuǎn)載自 http://tech.it168.com/j/2007-10-19/200710190919953.shtml

在單元測試時，我們盡量在屏蔽模塊間相互干擾的情況下，重點關(guān)注模塊內(nèi)部邏輯的正確性。而集成測試則是在將模塊整合在一起后進行的測試，它的目的在于發(fā)現(xiàn)一些模塊間整合的問題。有些功能很難通過模擬對象進行模擬，相反它們往往只能在真實模塊整合后，才能真正運行起來，如事務(wù)管理就是其中比較典型的例子。
按照Spring的推薦（原話：You should not normally use the Spring container for unit tests: simply populate your POJOs in plain JUnit tests!），在單元測試時，你不應(yīng)該依賴于Spring容器。換言之，你不應(yīng)該在單元測試時啟動ApplicatonContext并從中獲取Bean，相反你應(yīng)該通過模擬對象完成單元測試。而集成測試的前提則是事先裝配好模塊和模塊之間的關(guān)聯(lián)類，如將DAO層真實的UserDao和LoginLogDao裝配到UserServiceImpl再進行測試。具體裝配工作是在Spring配置文件中完成的，因此在一般情況下，集成測試需要啟動Spring容器，你可以在測試類中簡單地從Spring容器中取出目標(biāo)Bean進行測試。
需要測試的業(yè)務(wù)接口
假設(shè)我們的應(yīng)用中擁有一個UserService業(yè)務(wù)層接口，它擁有4個業(yè)務(wù)方法，其代碼如下所示：
代碼清單1 UserServie接口

   1: package com.baobaotao.service;
   2: import com.baobaotao.domain.User;
   3: import org.springframework.transaction.annotation.Transactional;
   4: @Transactional
   5: public interface UserService {
   6: boolean hasMatchUser(String userName,String password);
   7: User findUserByUserName(String userName);
   8: void loginSuccess(User user);
   9: void registerUser(User user);
  10: }

我們通過UserServiceImpl對UserService提供了實現(xiàn)：
代碼清單2 UserServiceImpl實現(xiàn)UserService接口

   1: package com.baobaotao.service;
   2: import com.baobaotao.dao.LoginLogDao;
   3: import com.baobaotao.dao.UserDao;
   4: import com.baobaotao.domain.LoginLog;
   5: import com.baobaotao.domain.User;
   6: public class UserServiceImpl implements UserService {
   7: private UserDao userDao;
   8: private LoginLogDao loginLogDao;
   9: public boolean hasMatchUser(String userName, String password) {
  10: int matchCount =userDao.getMatchCount(userName, password);
  11: return matchCount > 0;
  12: }
  13: public User findUserByUserName(String userName) {
  14: return userDao.findUserByUserName(userName);
  15: }
  16: public void loginSuccess(User user) {
  17: user.setCredits( 5 + user.getCredits());
  18: LoginLog loginLog = new LoginLog();
  19: loginLog.setUserId(user.getUserId());
  20: loginLog.setIp(user.getLastIp());
  21: loginLog.setLoginDate(user.getLastVisit());
  22: userDao.updateLoginInfo(user);
  23: loginLogDao.insertLoginLog(loginLog);
  24: }
  25: public void setLoginLogDao(LoginLogDao loginLogDao) {
  26: this.loginLogDao = loginLogDao;
  27: }
  28: public void setUserDao(UserDao userDao) {
  29: this.userDao = userDao;
  30: }
  31: }

UserServiceImpl引用了兩個DAO層的類（UserDao和LoginLogDao）共同實現(xiàn)UserService的接口，在UserServiceImpl開放使用之前，我們有必須對其進行集成測試，以保證實現(xiàn)邏輯的正確性。

使用傳統(tǒng)的方式進行集成測試
下面，我們通過傳統(tǒng)的方式為UserServiceImpl編寫了一個集成測試用例，測試代碼如下所示：
代碼清單 3 TestUserService：UserService集成測試用例

   1: package com.baobaotao.service;

   2: …

   3: public class TestUserService extends TestCase {

   4: public ApplicationContext ctx = null; ①Spring容器引用

   5: private static String[] CONFIG_FILES = { ②Spring配置文件

   6: "baobaotao-dao.xml",

   7: "baobaotao-service.xml" };

   8: protected void setUp() throws Exception {③啟動Spring容器

   9: ctx = new FileSystemXmlApplicationContext(CONFIG_FILES);

  10: }

  11: public void testHasMatchUser() { ④測試方法一

  12: ④-1從容器中獲取Bean

  13: UserService userService = (UserService) ctx.getBean("userService");

  14: boolean b1 = userService.hasMatchUser("admin", "123456");

  15: boolean b2 = userService.hasMatchUser("admin", "1111");

  16: assertTrue(b1);

  17: assertTrue(!b2);

  18: }

  19: public void testAddLoginLog() {⑤測試方法二

  20: ⑤-1從容器中獲取Bean

  21: UserService userService = (UserService) ctx.getBean("userService");

  22: User user = userService.findUserByUserName("admin");

  23: user.setUserId(1);

  24: user.setUserName("admin");

  25: user.setLastIp("192.168.12.7");

  26: user.setLastVisit(new Date());

  27: userService.loginSuccess(user);

  28: }

  29: …//省略其余的測試方法 

  30: } 

在這個測試用例中，我們使用了最原始的JUnit的TestCase進行集成測試，乍一看并沒有多大的問題，但仔細分析一下，我們就可以總結(jié)出以下四點明顯的不足：
1)導(dǎo)致多次Spring容器初始化問題：根據(jù)JUnit測試方法的調(diào)用流程（參見錯誤！未找到引用源。小節(jié)的描述），每執(zhí)行一個測試方法都會創(chuàng)建一個TestUserService實例并調(diào)用setUp()方法。由于我們在setUp()方法中初始化Spring容器，這意味著TestUserService有多少個測試方法，Spring容器就會被重復(fù)初始化多少次。雖然初始化Spring容器的速度并不會太慢，但由于可能會在Sprnig容器初始化時執(zhí)行加載Hibernate映射文件等耗時的操作，如果每執(zhí)行一個測試方法都必須重復(fù)初始化Spring容器，則對測試性能的影響是不容忽視的；
2)需要使用硬編碼方式手工獲取Bean：在④-1和⑤-1處，我們通過ctx.getBean()方法從Spring容器中獲取需要測試的目標(biāo)Bean，并且還要進行強制類型轉(zhuǎn)換的造型操作。這種乏味的操作迷漫在測試用例的代碼中，讓人覺得繁瑣不堪；
3)數(shù)據(jù)庫現(xiàn)場容易遭受破壞：⑤處的測試方法會對數(shù)據(jù)庫記錄進行插入操作，雖然是針對開發(fā)數(shù)據(jù)庫進行操作，但如果數(shù)據(jù)操作的影響是持久的，可能會影響到后面的測試行為。舉個例子，你在測試方法中插入一條ID為1的User記錄，第一次運行不會有問題，第二次運行時，就會因為主鍵沖突而導(dǎo)致測試用例失敗。所以應(yīng)該既能夠完成功能邏輯檢查，又能夠在測試完成后恢復(fù)現(xiàn)場，不會留下“后遺癥”；
4)沒有對數(shù)據(jù)操作正確性進行檢查：⑤處我們向登錄日志表插入了一條成功登錄日志，可是我們卻沒有對t_login_log表中是否確實添加了一條記錄進行檢查。原來我們的方式是打開數(shù)據(jù)庫，肉眼觀察是否插入了相應(yīng)的記錄，但這嚴重違背了自動測試的原則。試想，你在測試包括成千上萬個數(shù)據(jù)操作行為的程序時，如何用肉眼進行檢查？
既然使用傳統(tǒng)方式對Spring應(yīng)用進行集成測試存在這么多不足，Spring責(zé)無旁貸地擔(dān)當(dāng)起革新之任。它通過擴展JUnit框架提供了一套專門測試Spring應(yīng)用的有力工具。借助Spring集成測試工具的幫助，以上所羅列的種種問題將冰消雪融、云開霧散。

Spring在org.springframework.test包中為測試提供了幾個有用的類，它們都是JUnit TestCase的子類。通過層層擴展，不斷豐富測試的功能，我們可以通過下圖了解這些類的繼承關(guān)系：

圖 1 Spring測試工具類
下面，我們來逐個了解這棵承繼類樹中每個節(jié)點測試類的功用，第一個要認識的是直接擴展于TestCase的ConditionalTestCase測試類。
ConditionalTestCase
如果你直接通過擴展TestCase創(chuàng)建測試用例，則所有帶test前綴的測試方法都會被毫無例外地執(zhí)行。而ConditionalTestCase可以讓你在某些情況下，有選擇地關(guān)閉掉一些測試方法，不讓他們在測試用例中執(zhí)行。這給開發(fā)者帶來了很大的靈活性，因為他們可以在某次測試中關(guān)閉掉一些測試方法，而僅運行當(dāng)前特別關(guān)注的測試方法，將問題域聚集到一定范圍內(nèi)。
如果你要關(guān)閉某個測試方法行，僅需實現(xiàn)ConditionalTestCase的 isDisabledInThisEnvironment(String testMethodName)方法就可以了，ConditionalTestCase在運行每一個測試方法前會根據(jù)isDisabledInThisEnvironment()方法判斷是簡單放棄目標(biāo)方法的運行，還是按正常方式執(zhí)行之。該方法默認情況下對所有的測試方法都返回false，也即執(zhí)行所有的測試方法。讓我們來看一個具體例子：
代碼清單 4 ConditionalTest1：有條件執(zhí)行測試方法

   1: package com.baobaotao.test;

   2: import org.springframework.test.ConditionalTestCase;

   3: public class ConditionalTest1 extends ConditionalTestCase {

   4: ①被忽略不執(zhí)行的測試方法

   5: private static String[] IGNORED_METHODS = {"testMethod1","testMethod3"};

   6: @Override

   7: protected boolean isDisabledInThisEnvironment(String testMethodName) {②所有在

   8: for (String method : IGNORED_METHODS) { IGNORED_METHODS數(shù)組中

   9: if (method.equals(testMethodName)) { 的方法都忽略執(zhí)行。

  10: return true;

  11: }

  12: }

  13: return false;

  14: }

  15: public void testMethod1(){ ③不執(zhí)行

  16: System.out.println("method1");

  17: }

  18: public void testMethod2(){ ④執(zhí)行

  19: System.out.println("method2");

  20: }

  21: public void testMethod3(){ ⑤不執(zhí)行

  22: System.out.println("method3");

  23: }

  24: } 

如果我們直接承繼JUnit的TestCase，③、④及⑤處的三個測試方法都會被執(zhí)行，但現(xiàn)在我們通過繼承ConditionalTestCase編寫測試類，并覆蓋了isDisabledInThisEnvironment()方法，當(dāng)測試方法名位于IGNORED_METHODS數(shù)組中時，測試方法就被旁路掉了。因此當(dāng)運行ConditionalTest1時，你會發(fā)現(xiàn)只有④處的testMethod2()測試方法得到了執(zhí)行，其它兩個測試方法看起來也被成功執(zhí)行，只不過會程序日志會給出報告，告訴你哪些測試方法是真正被執(zhí)行，而哪些方法被“偽執(zhí)行”的。
ConditionalTestCase其實可用于任何程序的單元測試中，它本身并沒有和Spring容器有任何關(guān)聯(lián)，它僅添加了一個按條件執(zhí)行測試方法的功能。
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”形式指定的資源被當(dāng)成類路徑資源處理；
? String[] getConfigPaths()：以“/”開頭的地址被當(dāng)成類路徑處理，如“/com/baobaotao/beans.xml”，而未以“/”開頭的地址被當(dāng)成相對于測試類所在包的文件路徑，如“beans.xml”表示配置文件在測試類所在類包的目錄下；
? String getConfigPath()：和getConfigPaths()類似，在僅需指定一個配置文件中使用。
以上三個方法，它們的優(yōu)先級和我們介紹的先后順序?qū)?yīng)，也就是說，當(dāng)你在子類中覆蓋了getConfigLocations()方法后，其它兩個方法就沒有意義了。所以你僅需選擇三者當(dāng)中適合的方法進行覆蓋，而沒有必要同時覆蓋多個方法。
AbstractSingleSpringContextTests將根據(jù)這些方法指定的Spring配置文件初始化Spring容器，然后將Spring容器引用添加到static緩存中。并通過getApplicationContext()向子類開放ApplicationContext的引用。
一般情況下，所有的測試類和測試方法都可以共享這個Spring容器直到測試完結(jié)，不過在某些極端情況下，測試方法可能會對Spring容器進行改動（比如通過程序改變Bean的配置定義），如果這種改變對于其它測試方法來說是有干擾的，這就相當(dāng)于“弄臟”了作為測試現(xiàn)場的Spring容器，因此在下一個測試方法執(zhí)行前必須“抹除”這個改變。你可以簡單地在會“弄臟”Spring容器的測試方法中添加setDirty()方法向AbstractSingleSpringContextTests報告這一行為，這樣在下一個測試方法執(zhí)行前，AbstractSingleSpringContextTests就會重新加載Spring容器以修補被“弄臟”的部分。
雖然你可以直接繼承AbstractSpringContextTests或AbstractSingleSpringContextTests創(chuàng)建自己的集成測試用例，不過你大可不必如此著急。Spring已經(jīng)提供了幾個功能齊全、實踐性更強的子類，讓我們繼續(xù)探索Spring集成測試工具類的精彩篇章吧。

一般集成測試
應(yīng)該說，Spring通過AbstractSpringContextTests或AbstractSingleSpringContextTests準(zhǔn)備好了集成測試的一些基礎(chǔ)設(shè)施，在建筑學(xué)上，這叫夯實地基，而AbstractDependencyInjectionSpringContextTests是在此地基之上建起的第一幢樓房。
AbstractDependencyInjectionSpringContextTests所新添的主要功能是其子類的屬性能被Spring容器中的Bean自動裝配，你無需手工通過ApplicationContext#getBean()從容器中獲取目標(biāo)Bean自行裝配。它很好回答了前面我們所指出第2)問題，下面我們通過實例進行學(xué)習(xí)：

   1: package com.baobaotao.test;
   2: import org.springframework.test.AbstractDependencyInjectionSpringContextTests;
   3: import com.baobaotao.service.UserService;
   4: public class DependencyInjectionCtxTest
   5: extends AbstractDependencyInjectionSpringContextTests {
   6: private UserService userService;
   7: public void setUserService(UserService userService) {①該屬性設(shè)置方法會被自動調(diào)動
   8: this.userService = userService;
   9: }
  10: @Override
  11: protected String[] getConfigLocations() { ②指定Spring配置文件所在位置
  12: return new String[]{"baobaotao-service.xml","baobaotao-dao.xml"};
  13: }
  14: public void testHasMatchUser(){ ③測試方法
  15: boolean match = userService.hasMatchUser("tom","123456");
  16: assertEquals(true, match);
  17: }
  18: …
  19: } 
代碼清單 5 DependencyInjectionCtxTest
在②處，我們指定了Spring配置文件所在的位置，AbstractDependencyInjectionSpringContextTests將使用這些配置文件初始化好Spring容器，并將它們保存于static的緩存中。然后馬上著手根據(jù)類型匹配機制（byType），
自動將Spring容器中匹配測試類屬性的Bean通過Setter注入到測試類中。為了方便說明這一重要的特性，我們先看一下baobaotao-service.xml的內(nèi)容： 

   1: <beans>

   2: <tx:annotation-driven/>

   3: ①按類型匹配于DependencyInjectionCtxTest的userService屬性

   4: <bean id="userService" class="com.baobaotao.service.UserServiceImpl">

   5: <property name="userDao" ref="userDao"/>

   6: <property name="loginLogDao" ref="loginLogDao"/>

   7: </bean>

   8: …

   9: </beans> 

根據(jù)baobaotao-service.xml配置文件的內(nèi)容，我們知道Spring容器中有一個UserService Bean，AbstractDependencyInjectionSpringContextTests探測到Spring容器中存在一個匹配于userService屬性的Bean后，就將其注入到DependencyInjectionCtxTest的userService屬性中。userService是這個集成測試類的測試固件，因此我們說AbstractDependencyInjectionSpringContextTests可以自己裝配測試固件。

解決自動裝配問題
如果Spring容器中擁有多個匹配UserService類型的Bean，由于Spring沒有足夠的信息做出取舍決策，因此會拋出UnsatisfiedDependencyException異常。假設(shè)我們采用以下傳統(tǒng)的事務(wù)管理的配置方式對UserService進行配置，按類型匹配的自動裝配機制就會引發(fā)問題：
①用于被代理的目標(biāo)Bean，按類型匹配于UserService

   1: <bean id="userServiceTarget" class="com.baobaotao.service.UserServiceImpl">

   2: <property name="userDao" ref="userDao" />

   3: <property name="loginLogDao" ref="loginLogDao"></property>

   4: </bean> 

②通過事務(wù)代理工廠為UserServiceImpl創(chuàng)建的代理Bean，也按匹配于UserService

   1: <bean id="userService"

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

   3: <property name="transactionManager" ref="transactionManager" />

   4: <property name="target" ref="userServiceTarget" />

   5: <property name="transactionAttributes">

   6: …

   7: </property>

   8: </bean> 

由于①處和②處的Bean都按類型匹配于UserService，在對DependencyInjectionCtxTest的userService屬性進行自動裝配將會引發(fā)問題。有兩種針對該問題的解決辦法：
? 調(diào)整配置文件，使按類型匹配于UserService的Bean僅有一個，具體有以下兩個方法：
? 將①處的Bean作為②處的內(nèi)部Bean進行裝配；
? 使用基于注解驅(qū)動的事務(wù)管理配置機制，這樣就無需在配置文件中定義兩個UserService的Bean了。關(guān)于注解驅(qū)動事務(wù)管理配置的詳細信息，請參見9.6小節(jié)的內(nèi)容。
? 改變DependencyInjectionCtxTest的自動裝配機制：Spring默認使用byType類型的自動裝配機制，但它允許你通過setAutowireMode()的方法改變默認自動裝配的機制，比如你可以調(diào)用setAutowireMode(AUTOWIRE_BY_NAME)方法啟用按名稱匹配的自動裝配機制。AbstractDependencyInjectionSpringContextTests定義了三個代表自動裝配機制類型的常量，分別說明如下：
? AUTOWIRE_BY_TYPE：按類型匹配的方式進行自動裝配，這個默認的機制；
? AUTOWIRE_BY_NAME：按名字匹配的方式進行自動裝配
? AUTOWIRE_NO：不使用自動裝配機制，這意味著你需要手工調(diào)用getBean()進行裝配。
現(xiàn)在我們解決了在自動裝配時，因Spring容器中存在多個匹配Bean而導(dǎo)致的問題，接下來讓我們考察另一個自動裝配的問題。
依賴檢查
假設(shè)我們在DependencyInjectionCtxTest添加一個User類型的屬性并提供Setter方法，而Spring容器中沒有匹配該屬性的Bean：

   1: package com.baobaotao.test;

   2: …

   3: import com.baobaotao.domain.User;

   4: public class DependencyInjectionCtxTest extends AbstractDependencyInjectionSpringContextTests {

   5: private User user;

   6: public void setUser(User user) {

   7: this.user = user;

   8: }

   9: …

  10: } 

猜想一下重新運行DependencyInjectionCtxTest將會發(fā)生什么情況呢？答案可能讓你失望：UnsatisfiedDependencyException再次象黑幕一樣降臨。在默認情況下， AbstractDependencyInjectionSpringContextTests要求所有屬性都能在Spring容器中找到對應(yīng)Bean，否則拋出異常。
仔細思考一下，這種運行機制并非沒有道理，因為既然你已經(jīng)提供了Setter方法，就相當(dāng)于給出了這樣的暗示信息：“這個屬性測試類自身創(chuàng)建不了，必須由外部提供”。而在使用自動裝配機制的情況下，測試類屬性自動從Spring容器中注入匹配的屬性，一般情況下不會手工去調(diào)用Setter方法準(zhǔn)備屬性。
如果你出于一些特殊的理由，希望在采用自動裝配的情況下，如果有屬性未得到裝配也不在乎，那么你可以在測試類構(gòu)造函數(shù)中調(diào)用setDependencyCheck(false)方法達到目的：

   1: package com.baobaotao.test;

   2: …

   3: public class DependencyInjectionCtxTest extends AbstractDependencyInjectionSpringContextTests {

   4: public DependencyInjectionCtxTest(){

   5: setDependencyCheck(false); ①告知不進行屬性依賴性檢查

   6: }

   7: …

   8: } 

這個AbstractDependencyInjectionSpringContextTests就不會對測試類有些屬性找不到匹配Bean而拋出異常了。

在不提供Setter方法的情況下自動注入
大多數(shù)IDE都提供了為屬性變量自動生成Setter方法的操作，因此客觀地說，為屬性編寫一個Setter方法的工作根本不值一提。如果你覺得眾多的Setter方法影響了視覺感觀，但又希望享受測試類屬性自動裝配的好處，Spring也不會讓你失望的。你需要做的是以下兩步的工作：
1) 將需要自動裝配的屬性變量聲明為protected；
2) 在測試類構(gòu)造函數(shù)中調(diào)用setPopulateProtectedVariables(true)方法。

   1: package com.baobaotao.test;

   2: …

   3: public class DependencyInjectionCtxTest extends AbstractDependencyInjectionSpringContextTests {

   4: protected UserService userService; ①將屬性聲明為protected

   5: // public void setUserService(UserService userService) { ②大膽將Setter方法移除掉

   6: // this.userService = userService;

   7: // } 

   8: public DependencyInjectionCtxTest(){

   9: setDependencyCheck(false);

  10: setPopulateProtectedVariables(true); ③啟用直接對屬性變量進行注釋的機制

  11: }

  12: …

  13: } 

將屬性聲明為protected后并通過setPopulateProtectedVariables(true)啟用對屬性變量直接注入的機制（啟用反射機制注入），你就可以避免為屬性變量編寫對應(yīng)的Setter方法了。
提示 屬性如果聲明為public，雖然你也調(diào)用了setPopulateProtectedVariables(true)方法，屬性變量依然不會被自動注入。所以這種機制僅限于protected的屬性變量。
方便地恢復(fù)測試數(shù)據(jù)庫現(xiàn)場
我們現(xiàn)在已經(jīng)可以通過AbstractDependencyInjectionSpringContextTests的屬性自動裝配機制方便地建立起測試固件，省卻手工調(diào)用getBean()自行準(zhǔn)備測試固件的煩惱。當(dāng)我們對UserService的hasMatchUser()和findUserByUserName()方法進行測試時，不會有任何問題，因為這兩個方法僅對數(shù)據(jù)庫執(zhí)行讀操作。但UserService以下兩個接口方法會對數(shù)據(jù)庫執(zhí)行更改操作：

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

當(dāng)我們對這兩個接口方法進行測試時，它們將會在數(shù)據(jù)庫中產(chǎn)生持久化數(shù)據(jù)?？紤]對registerUser(User user)方法進行測試時，我們可能編寫如下所示的測試方法：

   1: public void testRegisterUser(){

   2: User user = new User();

   3: user.setUserId(2);

   4: user.setUserName("john");

   5: user.setPassword("123456");

   6: userService.registerUser(user);

   7: } 

當(dāng)?shù)谝淮纬晒\行testRegisterUser()測試方法時，將在數(shù)據(jù)庫中產(chǎn)生一條主鍵為2的記錄，如何第二次重新運行testRegisterUser()測試方法其結(jié)果將不言自明：因主鍵沖突導(dǎo)致測試方法執(zhí)行失敗，最終報告測試用例沒有通過。在這種情況下，測試用例未通過并不是因為UserServiceImpl#registerUser(User user)存在邏輯錯誤，而是因為測試方法的積累效應(yīng)導(dǎo)致外在設(shè)施的現(xiàn)場發(fā)生變化而引起的問題。
為了防止這種問題，測試用例必須在保證不對數(shù)據(jù)庫狀態(tài)產(chǎn)生持久化變化的情況下，對目標(biāo)類的數(shù)據(jù)操作邏輯正確性進行檢測。乍一聽這一要求有點貌似于“既想馬兒跑，又想馬兒不吃草”一樣充滿悖論，實則不然。只要我們讓測試方法不提交事務(wù)，在測試完后自動回滾事務(wù)，就皆大歡喜了。

讓測試方法自動擁有回滾能力
AbstractTransactionalSpringContextTests專為解決以上問題而生，也就是說前面我們所提及的第3)個問題在此得到了回答。只要繼承該類創(chuàng)建測試用例，在默認情況下，測試方法中所包含的事務(wù)性數(shù)據(jù)操作都會在測試方法返回前被回滾。由于事務(wù)回滾操作發(fā)生在測試方法返回前的點上，所以你可以象往常一樣在測試方法體中對數(shù)據(jù)操作的正確性進行校驗。

   1: package com.baobaotao.service;
   2: import org.springframework.test.AbstractTransactionalSpringContextTests;
   3: import com.baobaotao.domain.User;
   4: public class UserServiceIntegrateTest extends AbstractTransactionalSpringContextTests {
   5: private UserService userService;
   6: public void setUserService(UserService userService) {
   7: this.userService = userService;
   8: }
   9: @Override
  10: protected String[] getConfigLocations() {
  11: return new String[]{"baobaotao-service.xml", "baobaotao-dao.xml"};
  12: }
  13: public void testRegisterUser(){ ①測試方法中的數(shù)據(jù)操作將在方法返回前被回滾，不會對數(shù)據(jù)庫
  14: User user = new User(); 產(chǎn)生永久性數(shù)據(jù)操作，第二次運行該測試方法時，依舊可以
  15: user.setUserId(2); 成功運行。
  16: user.setUserName("john");
  17: user.setPassword("123456");
  18: userService.registerUser(user);
  19: User user1 = userService.findUserByUserName("john"); ②對數(shù)據(jù)操作進行
  20: assertEquals(user.getUserId(), user1.getUserId()); 正確性檢驗
  21: }
  22: } 
代碼清單 6 UserServiceIntegrateTest：
如果testRegisterUser()是直接繼承于AbstractDependencyInjectionSpringContextTests類的測試方法，則重復(fù)運行該測試方法就會發(fā)生數(shù)據(jù)沖突問題。但因為它位于繼承于
AbstractTransactionalSpringContextTests的測試用例類中，測試方法中對數(shù)據(jù)庫的操作會被正確回滾，所以重復(fù)運行不會有任何問題。 
如果你確實希望測試方法中對數(shù)據(jù)庫的操作持久生效而不是被回滾，Spring也可以滿足你的要求，你僅需要在測試方法中添加setComplete()方法就可以了。 

   1: public void testRegisterUser(){

   2: …

   3: User user1 = userService.findUserByUserName("john");

   4: assertEquals(user.getUserId(), user1.getUserId());

   5: setComplete(); ①測試方法中的事務(wù)性數(shù)據(jù)操作將被提交

   6: } 

AbstractTransactionalSpringContextTests還擁有幾個可用于初始化測試數(shù)據(jù)庫，并在測試完成后清除測試數(shù)據(jù)的方法，分別介紹如下：
? onSetUpBeforeTransaction()/onTearDownAfterTransaction()：子類可以覆蓋這兩個方法，以便在事務(wù)性測試方法運行的前后執(zhí)行一些數(shù)據(jù)庫初始化的操作并在事務(wù)完成后清除之；
? onSetUpInTransaction()/onTearDownInTransaction()：這對方法和前面介紹的方法完成相同的功能，只不過它們是在測試方法的相同事務(wù)中執(zhí)行的。
AbstractTransactionalSpringContextTests另外還提供了一組用于測試延遲數(shù)據(jù)加載的方法：endTransaction()/startNewTransaction()。我在測試Hibernate、JPA等允許延遲數(shù)據(jù)加載的應(yīng)用時，如何模擬數(shù)據(jù)在Service層事務(wù)中被部分加載，當(dāng)傳遞到Web層時重新打開事務(wù)完成延遲部分數(shù)據(jù)加載的測試場景呢？這兩個方法即為此用途而生：你可以在測試方法中顯式調(diào)用endTransaction()方法以模擬從Service層中獲取部分數(shù)據(jù)后返回，爾后，再通過startNewTransaction()開啟一個和原事務(wù)無關(guān)新事務(wù)——模擬在Web層中重新打開事務(wù)，接下來你就可以訪問延遲加載的數(shù)據(jù)，看是否一切如期所料了。
在代碼清單 6的②處，我們通過UserService#findUserByUserName()方法對前面registerUser(user)方法數(shù)據(jù)操作的正確性進行檢驗。應(yīng)該說，我們非常幸運，因為在UserService中剛好存在一個可用于檢測registerUser(user)數(shù)據(jù)操作正確性的方法。讓我們考慮另外的一種情況：要是 UserService不存在這樣的方法，我們該如何檢測registerUser(user)數(shù)據(jù)操作結(jié)果的正確性呢？顯然我們不能使用肉眼觀察的方法，那難道為了驗證數(shù)據(jù)操作正確性專門編寫一個配合性的數(shù)據(jù)訪問類不成？
通過JDBC訪問數(shù)據(jù)庫，檢測數(shù)據(jù)操作正確性
正當(dāng)我們“山重水復(fù)疑無路”的時候，讓我們再往前走上一程，柳暗花明將倏忽而至
——AbstractTransactionalDataSourceSpringContextTests就是花開景明之所。該類繼承于AbstractTransactionalSpringContextTests，它添加了一個JdbcTemplate，你可以借由此道快意直達數(shù)據(jù)庫。它自動使用Spring容器中的數(shù)據(jù)源（DataSource）創(chuàng)建好一個JdbcTemplate實例并開放給子類使用。值得注意的是，如果你采用byName自動裝配機制，數(shù)據(jù)源Bean的名稱必須取名為“dataSource”。
讓我們對UserServiceIntegrateTest進行改造，以便讓其自動擁有訪問數(shù)據(jù)庫的設(shè)施（JdbcTemplate），并用靈活的方法訪問數(shù)據(jù)庫進行數(shù)據(jù)操作的檢驗，其代碼如下所示：

代碼清單 7 UserServiceIntegrateWithJdbcTest
   1: package com.baobaotao.service;
   2: import org.springframework.test.AbstractTransactionalDataSourceSpringContextTests;
   3: …
   4: public class UserServiceIntegrateWithJdbcTest
   5: extends AbstractTransactionalDataSourceSpringContextTests {①注意：繼承類發(fā)生調(diào)整
   6: private UserService userService;
   7: public void setUserService(UserService userService) {
   8: this.userService = userService;
   9: }
  10: @Override
  11: protected String[] getConfigLocations() {
  12: return new String[]{"baobaotao-service.xml", "baobaotao-dao.xml"};
  13: }
  14: public void testRegisterUser(){
  15: User user = new User();
  16: user.setUserId(2);
  17: user.setUserName("john");
  18: user.setPassword("123456");
  19: userService.registerUser(user);
  20: String sqlStr = " SELECT user_id FROM t_user WHERE user_name ='john' ";
  21: int userId = jdbcTemplate.queryForInt(sqlStr); ①可以直接使用JdbcTemplate訪問數(shù)據(jù)庫了
  22: assertEquals(user.getUserId(), userId);
  23: setComplete();
  24: }
  25: }
jdbcTemplate是AbstractTransactionalDataSourceSpringContextTests類中定義的，子類可以直接使用它訪問數(shù)據(jù)庫。這樣我們就可以靈活地訪問數(shù)據(jù)庫以檢驗?zāi)繕?biāo)測試方法的數(shù)據(jù)操作正確性。至此，我們終于畢其功于
一役于AbstractTransactionalDataSourceSpringContextTests，順利解決前面我們中指出的最后問題。 只要你通過擴展AbstractTransactionalSpringContextTests及其子類創(chuàng)建測試用例，所有測試方法都會工作了
事務(wù)環(huán)境下。也就是說，即使某些測試方法不需要訪問數(shù)據(jù)庫，也會產(chǎn)生額外的事務(wù)管理開銷，是否可以對測試方法啟用事務(wù)管理的行為進行控制呢？此外，在一些情況下，除對目標(biāo)方法邏輯運行的正確性進行檢驗外，我們還希望
對目標(biāo)方法的運行性能進行測試：如當(dāng)目標(biāo)方法運行時間超過200毫秒時，則測試用例視為未通過。諸如此類的問題，我們目前學(xué)習(xí)到的知識還不能很好的應(yīng)付。Spring 2.0新增了注解驅(qū)動的測試工具為我們指明了道路，你僅需要
通過簡單為測試方法標(biāo)注注解，我們剛才提出的“疑難”問題就可以迎刃而解了。
小結(jié)
本文我們講述了使用Spring提供的一套測試工具對Spring應(yīng)用程序進行集成測試所需的所有知識。 
Spring建議你不應(yīng)該在單元測試時使用到Spring容器，你應(yīng)該在集成測試時才使用到Spring容器。手工創(chuàng)建測試固件或者手工裝配測試固件的工作都是單調(diào)乏味沒有創(chuàng)意的工作，通過使用Spring為集成測試提供了幫助類，你就
可以享受測試固件自動裝配的好處，將精力集中到目標(biāo)類邏輯測試編寫的工作上。 應(yīng)該說大部分的Java應(yīng)用都是Web應(yīng)用，而大部分的Java Web應(yīng)用都是數(shù)據(jù)庫相關(guān)的應(yīng)用，對數(shù)據(jù)庫應(yīng)用進行測試經(jīng)常要考慮數(shù)據(jù)準(zhǔn)備、數(shù)據(jù)庫現(xiàn)
場恢復(fù)、靈活訪問數(shù)據(jù)以驗證數(shù)據(jù)操作正確性等等的問題。這些問題如果沒有一個
很好的支持工具，將給編寫測試用例造成挑戰(zhàn)，幸好Spring都為我們搭建好滿足這些需求的測試平臺，你僅需要在此基礎(chǔ)上編寫特定的測試用例就可以了。