我的對持續集成的理解和實踐

    目前團隊人數不多，也沒有真正意義上的測試人員，那麼如何保證代碼質量呢？最近看了《持續交付——發佈可靠軟件的系統方法》很受啓發，忽然也想通了不少集成開發工具的設計理念，並作了一些實踐，特別記錄下來與衆人分享。

如何保證代碼質量

    我以爲根本就是持續集成，確保代碼服務器上的版本始終是可運行的。粗粒度上就是把功能分階段作，每一個階段的功能是完整可發佈的，這樣有不少好處，儘早看到效果來調整、儘早發現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很好用，語法很漂亮，雖然暫時沒打算用。

 

參考資料： 1. unitils cookbook: http://unitils.sourceforge.net/cookbook.html 2. 開發測試的那些事兒: http://stamen.iteye.com/blog/1466145 3. 測試整合之王Unitils: http://stamen.iteye.com/blog/1480316 4. 使用unitils測試Service層: http://stamen.iteye.com/blog/1485837 5. 《持續交付——發佈可靠軟件的系統方法》