個人對持續整合的理解和實踐

目前團隊人數很少，也沒有真正意義上的測試人員，那麼如何保證程式碼質量呢？最近看了《持續交付——釋出可靠軟體的系統方法》很受啟發，突然也想通了很多整合開發工具的設計理念，並做了一些實踐，特別記錄下來與眾人分享。

　　如何保證程式碼質量

　　我覺得根本就是持續整合，確保程式碼伺服器上的版本始終是可執行的。粗粒度上就是把功能分階段做，每個階段的功能是完整可釋出的，這樣有很多好處，儘早看到效果來調整、儘早發現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很好用，語法很漂亮，雖然暫時沒打算用。

====================================分割線================================

最新內容請見作者的GitHub頁：http://qaseven.github.io/