在像 Eclipse 那樣的 IDE 中或者比如在 Ant 構建腳本中運行單元測試是確保應用程序質量的一個很好的開始；然而，版本控制庫（如 Subversion）中的源代碼一改變，在單獨無變動的構建機上運行單元測試就有助于檢驗開發生命周期中的問題。而且，運行各種類型的開發人員測試，如組件測試、功能測試和性能測試，能夠在開發生命周期中更早地 將問題顯示出來。
關于本系列
作為開發人員，我們的工作就是為終端用戶實現過程自動化；然而，很多開發人員卻忽略了將自己的開發過程自動化的機會。為此，我編寫了 讓開發自動化 這個系列的文章，專門探討軟件開發過程自動化的實際應用，并教您何時 以及如何 成功地應用自動化。
通常在持續集成（CI）環境中運行的開發人員測試有效地扮演著代碼質量聚光燈的角色。這是因為如果能有效地編寫這些測試，則幾乎能夠在問題（如缺陷）產生之時就將其發現。不經常運行測試通常就不怎么有效，因為從產生缺陷到發現該缺陷的時間相隔很長，但持續地（即，每一次代碼改變時）運行測試能確�？焖侔l現無意識的行為。
本文涵蓋下列內容：
通過 Ant 運行 JUnit 測試
使用 JUnit 和 DbUnit 執行更長時間的運行組件測試
使用 JUnitPerf 確定哪些方法花費時間過久而執行失敗
用 Selenium 運行基于 Web 的功能測試
用 Cobertura 訪問代碼覆蓋率
用 CruiseControl 進行持續測試
我提供一個關于不同類型開發人員測試的概覽，和一些可以添加到構建過程并使用 Continuous Integration 系統持續運行的例子。
按 JUnit 進行單元測試
有人稱之為單元測試，有人稱之為組件測試
經常提到的單元測試其實更像是一個組件級別的測試。組件測試通常驗證不止一個類，并且依賴于一些東西，如數據庫或其他重量級系統，如文件系統。但是更重要的是，在測試的基礎上進行測試，組件測試比單元測試運行時間更長。
有時，我聽到開發人員將開發人員測試這一術語與簡單的單元測試相混淆；然而，我發現將單元測試這一術語提練得更加明確很有幫助。對我來說，單元測試是快速運行的 測試，通常測試沒有大的外部依賴項（如數據庫）的單獨的類。例如，清單 1 定義了一個單元測試，該測試使用 JUnit 來驗證一個叫做 BeerDaoStub 的存根數據類。針對并未真正連接到數據庫的接口的測試技術是一種驗證業務功能的方法，使用該方法不會導致花費昂貴的設置成本。另外，這樣做可使測試保持為一個真正的單元測試。
清單 1. 一個簡單的單元測試
public void setUp() {
beerService = new BeerDaoStub();
}
public void testUnitGetBeer() {
Collection beers = beerService.findAll();
assertTrue(beers != null && beers.size() > 0);
}
一旦編寫了一些單元測試，就可以一直通過 IDE 運行這些測試，但您也想要將這些測試作為構建過程的一部分來運行。確保該測試通過構建過程成功運行意味著也能從 CI 構建的上下文中啟動這些相同的測試。
文章來源于領測軟件測試網 http://www.kjueaiud.com/