在開發(fā)基于Spring的應(yīng)用時(shí)，如果你還直接使用Junit進(jìn)行單元測試，那你錯(cuò)過了Spring為我們所提供的饕餮大餐了。使用Junit直接進(jìn)行單元測試有以下四大不足：

　　1）導(dǎo)致多次Spring容器初始化問題

　　根據(jù)JUnit測試方法的調(diào)用流程，每執(zhí)行一個(gè)測試方法都會(huì)創(chuàng)建一個(gè)測試用例的實(shí)例并調(diào)用setUp()方法。由于一般情況下，我們在setUp()方法中初始化Spring容器，這意味著如果測試用例有多少個(gè)測試方法，Spring容器會(huì)被重復(fù)初始化多次。雖然初始化Spring容器的速度并不會(huì)太慢，但由于可能會(huì)在Spring容器初始化時(shí)執(zhí)行加載Hibernate映射文件等耗時(shí)的操作，如果每執(zhí)行一個(gè)測試方法都必須重復(fù)初始化Spring容器，則對測試性能的影響是不容忽視的；

　　－－>使用Spring測試套件，Spring容器只會(huì)初始化一次！

　　2）需要使用硬編碼方式手工獲取Bean

　　在測試用例類中我們需要通過ctx.getBean()方法從Spirng容器中獲取需要測試的目標(biāo)Bean，并且還要進(jìn)行強(qiáng)制類型轉(zhuǎn)換的造型操作。這種乏味的操作迷漫在測試用例的代碼中，讓人覺得煩瑣不堪；

　�。�－>使用Spring測試套件，測試用例類中的屬性會(huì)被自動(dòng)填充Spring容器的對應(yīng)Bean ，無須在手工設(shè)置Bean！

　　3）數(shù)據(jù)庫現(xiàn)場容易遭受破壞

　　測試方法對數(shù)據(jù)庫的更改操作會(huì)持久化到數(shù)據(jù)庫中。雖然是針對開發(fā)數(shù)據(jù)庫進(jìn)行操作，但如果數(shù)據(jù)操作的影響是持久的，可能會(huì)影響到后面的測試行為。舉個(gè)例子，用戶在測試方法中插入一條ID為1的User記錄，第一次運(yùn)行不會(huì)有問題，第二次運(yùn)行時(shí)，會(huì)因?yàn)橹麈I沖突而導(dǎo)致測試用例失敗。所以應(yīng)該既能夠完成功能邏輯檢查，又能夠在測試完成后恢復(fù)現(xiàn)場，不會(huì)留下“后遺癥”；

　�。�－>使用Spring測試套件，Spring會(huì)在你驗(yàn)證后，自動(dòng)回滾對數(shù)據(jù)庫的操作，保證數(shù)據(jù)庫的現(xiàn)場不被破壞，因此重復(fù)測試不會(huì)發(fā)生問題！

　　4）不方便對數(shù)據(jù)操作正確性進(jìn)行檢查

　　假如我們向登錄日志表插入了一條成功登錄日志，可是我們卻沒有對t_login_log表中是否確實(shí)添加了一條記錄進(jìn)行檢查。一般情況下，我們可能是打開數(shù)據(jù)庫，肉眼觀察是否插入了相應(yīng)的記錄，但這嚴(yán)重違背了自動(dòng)測試的原則。試想在測試包括成千上萬個(gè)數(shù)據(jù)操作行為的程序時(shí)，如何用肉眼進(jìn)行檢查？

　�。�－>只要你繼承Spring的測試套件的用例類，你可以通過jdbcTemplate在同一事務(wù)中訪問數(shù)據(jù)庫，查詢數(shù)據(jù)的變化，驗(yàn)證操作的正確性！

　　Spring提供了一套擴(kuò)展于Junit測試用例的測試套件，使用這套測試套件完全解決了以上四個(gè)問題，讓我們測試Spring的應(yīng)用更加方便。現(xiàn)在我的項(xiàng)目中已經(jīng)完成摒棄Junit，而采用Spring的測試套件，確實(shí)帶來了很大的便利。嚴(yán)重推薦Springer使用這個(gè)測試套件。這個(gè)測試套件主要由org.springframework.test包下的若干類組成，使用簡單快捷，方便上手。