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<String> contexts = null;

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

  contexts = new ArrayList<String>();  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)   }}