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