Spring下業務層的UnitTest--4.15更新

磨蹭了很久，終於開始用UnitTest。原因一和大家一樣，不想晚上做噩夢，原因二是在Spring下對業務層TDD，能夠不需要Tomcat，完全擺脫對顯示層開發進度的依賴，而專注快速的開發業務層。

但是我們也只在業務層使用UnitTest，因為MVC中顯示層至今沒有什麼好的UnitTest方法(無論是不成才的httpUnit們還是笨重的GUI test工具)，而我們的 業務邏輯又嚴格封裝在業務層，Controler層只做個組裝分派的基本動作，沒必要花大力氣去測試。

在Spring下的測試很簡單，即使手寫ApplicationContext的載入與Bean的創建都很簡單，但在兩方面Spring提供了更大的方便

1.bean的動態注入

本來自己手工load也不麻煩,但只要你的testCase繼承Spring-mock.jar裡的AbstractDependencyInjectionSpringContextTests,你甚至只要把變量聲明為protected,就會獲得自動注入.

2.數據庫環境的維持

Spring的解決方法也十分簡單,他會為每個方法自動的,強制的rollback,這樣就不存在清理-維持的問題了,只要你的testCase繼承於 AbstractTransactionalDataSourceSpringContextTests.

同時,這個 AbstractTransactionalDataSourceSpringContextTests兼有上面AbstractDependencyInjectionSpringContextTests的功能.

3.進一步簡化

一來這兩個基類的名字都太長了, 二來還有一些公共的設定,比如在構造函數執行setPopulateProtectedVariables(true);這樣子只要聲明protected就會被動態注入,否則還要寫setter才會被動態注入. 比如一些公共的context文件的定義.

所以我們抽象了一個基類public class DAOTestCase extends AbstractTransactionalDataSourceSpringContextTests{ protected ArrayList contexts = null;

public DAOTestCase() { //設了這個,就能autowire by name,否則by setter. setPopulateProtectedVariables(true);

contexts = new ArrayList(); contexts.add("/applicationContext-Hibernate.xml"); contexts.add("/applicationContext-SetupService.XML"); }

public String[] getConfigLocations() { String[] tmp = new String[contexts.size()]; return contexts.toArray(tmp); }}

實際的子類public class CustomerDAOTest extends DAOTestCase{ protected CustomerDAO customerDAO;

public void testGetCustomer() throws Exception { Customer customer = customerDAO.lookCustomer(1); assertEquals((int)customer.getCustomerNo(),1) }}