目前團隊人數很少，也沒有真正意義上的
測試人員，那么如何保證代碼質量呢？最近看了《持續交付——發布可靠軟件的系統方法》很受啟發，突然也想通了很多集成開發工具的設計理念，并做了一些實踐，特別記錄下來與眾人分享。
如何保證代碼質量
我覺得根本就是持續集成，確保代碼服務器上的版本始終是可運行的。粗粒度上就是把功能分階段做，每個階段的功能是完整可發布的，這樣有很多好處，盡早看到效果來調整、盡早發現bug、有成果可以鼓舞士氣等等；細粒度上就是把每次提交的東西進行測試，讓問題盡早暴露盡早修復。
如何達到這個目標呢？原則就是讓重復的工作自動化，讓測試頻繁進行。具體來說就是自動化測試、自動化打包、自動化部署。
自動化測試就是為了能夠經常反復的測試才能更早的發現問題。為了讓開發人員勤于測試，所以測試的運行時間必須要夠短。持續集成推崇的方式是每次提交執行一次測試，這里只做單元測試以確保速度，這也是為什么grails里面把unit單獨拿出來鼓勵測試。
自動化打包我沒用高級的工具，就是利用ant+Ivy寫的打包腳本，并借用Grails的思想，通過不同的打包參數可以打出dev、test、prod的包，這樣就大大減少人工打包出錯的概率。
自動化部署目前我用sae倒是平臺就已經支持了，直接上傳war包以后，部署都是自動進行的。但是sae的問題就是你本地測試通過的東西，那個環境卻不一定行，無比尷尬。
測試種類與分工
測試種類的名詞有很多，且最后用的都有很多歧義，特別是集成測試更是有多種含義。我覺得最好理解的劃分就是：功能測試（單元測試，組件測試，驗收測試）和非功能測試（探索性測試、性能測試、容量測試）。只要能做成自動化的就是開發人員做的；沒有辦法自動化的就是測試人員做的。
其中，單元測試是不依賴外部只測試某一個類的，為了達到這個效果還有挺多工作的，外部依賴的類要用Mock來模擬，并且盡量不連接數據庫這些外部依賴。組件測試就是要有這些外部依賴了，也可以說成是功能測試。驗收測試就是模擬用戶行為做一系列操作，這個是在最終發布的時候做一次，確保用戶使用的正確性。
但注意，每個測試間要做到互相獨立，否則會大大增加維護難度。
我期望的效果
單元測試是好東西，但是其實我覺得組件測試是涵蓋單元的功能，只是運行時間更長一點而已，但為了減輕測試代碼的工作量，我想省去單元測試而全部采用組件 測試。組件測試有一個棘手問題就是用到數據庫，而數據庫是一個有狀態的，測試運行的先后順序都會影響測試結果，所以最好的辦法是讓每個測試執行完進行回 滾。
驗收測試是個剛學習到的理念，就是把用戶對某個功能的一系列操作放在一起進行功能效果驗收。雖然會有很大維護量，但是可以有效模擬用戶行為，對功能效果進行完整的測試，達到回歸測試的效果。
總結一下，就是利用組件測試達到頻繁測試的效果，用驗收測試達到回歸測試效果。
測試框架
為了達到以上效果有什么好的框架，我查了一圈資料，也試了幾個框架。Junit4還是被公認最簡單有效的框架，并且有眾多的擴展插件和IDE支持，但缺 點就是自身功能過于簡單。要實現每次測試完的回滾需要結合dbunit，要和spring集成也要自己實現，用到mock也有很多工具可選擇。
最后發現一個整合的測試框架Unitlis，它不但整合了以上需求，還簡化了配置操作，同時還實現了數據庫升級文件的版本管理。試用以后感覺很不錯，非常有愛。官方主頁是：http://unitils.sourceforge.net/summary.html。
我覺得Unitils有以下幾個比較顯著的優點：
1、基于反射的斷言非常強大，自動過濾掉null和空值，對數組也無視順序，真的是基于內容本身的比較。
2、集成了spring管理，都是用注解來聲明，非常清楚簡潔。
3、集成dbunit，配置簡化了很多配置，特別對事務回滾配置也很靈活、簡單。
4、自帶的Mock很好用，語法很漂亮，雖然暫時沒打算用。