0.準備一個乾淨的測試數據庫環境
這個是前提
1.測試數據準備
使用文本,excel,或者wiki等,準備測試sql以及測試數據
利用dbfit,dbutil等工具將準備的測試數據導入到數據庫中
2.執行dao方法
執行被測試的dao方法
3.測試結果斷言
利用dbfit,dbutil等工具,斷言測試結果數據和預計是否一致
4.所有數據回滾
其實,對於這個流程來說,目前的dao測試框架,支持的已經比較完美了
但是此類測試方法,也有明顯的缺點(或者不能叫缺點,叫使用比較麻煩的地方)
如下:
1.背上了一個數據庫環境.
不輕量
這是一個共享環境,誰也無法確保環境數據是否真正的乾淨
2.測試數據準備是一件麻煩的事情
新表,10幾個字段毫不爲奇;老表,50幾個字段甚至百來個字段,也偶有可見;無論是使用文本,excel,wiki,準備工作量,都是巨大的.
準備的數據,部分字段內容可以是無意義的,部分字段內容又是需要符合測試意圖(testcase設計目的),部分字段還是其他表的關聯字段.從而導致後續維護人員無法瞭解準備數據意圖.
(實踐中,也出現過,一同事在維護他人單元測試時,由於無法瞭解測試數據準備意圖,寧可重新刪除,自己準備一份)
3.預計結果數據準備也是一件麻煩的事情
理由如上
所以,理論上是完美的測試方案,在實踐過程中,卻是一件麻煩的事情.導致DAO單元測試維護困難.
分析了現狀,我們再來分析下,IBatis下DAO,程序員主要做了哪些編碼:
1. 寫了一份sqlmap.xml配置文件
2. 通過getSqlMapClientTemplate.doSomething($sqlID,$param), 執行語句
(當然,沒有使用spring的同學,也是使用了類似sqlMapClient.doSomething($sqlID,$param)方法)
而步驟2其實是框架替我們做了的事情,按照MOCK的思想,其實這部分代碼可以被MOCK的,那麼我們是否可以做如下假設:
只要sqlmap.xml中配置信息(主要包括resultmap和statement)是正確的,那麼執行結果也應該是正確的.
而我所謂的另類思路,就是基於這個假設,得出的:
IBatis下,DAO單元測試,我們拋棄揹負的數據庫環境,只要根據不同的條件,斷言不同的sql即可.
於是乎,封裝了一個IbatisSqlTester,可以根據sqlmap中的statement和傳入的條件參數,生成sql語句.
那麼,DAO單元測試就簡單了,脫離下數據庫環境:
http://www.blogjava.net/stone2083/archive/2010/08/12/328602.html