準備好開始在您的開發人員測試活動中大獲全勝嗎？在本期的 讓開發自動化 中，開發自動化專家 Paul Duvall 介紹了幾種自動化的開發人員測試，每一次改變源代碼都能夠運行這些測試。Paul 提供了 Selenium、DbUnit 和 JUnitPerf 測試的例子，即，如果經常 運行這些測試可以幫助您盡早發現應用程序的問題。
在像 Eclipse 那樣的 IDE 中或者比如在 Ant 構建腳本中運行單元測試是確保應用程序質量的一個很好的開始；然而，版本控制庫（如 Subversion）中的源代碼一改變，在單獨無變動的構建機上運行單元測試就有助于檢驗開發生命周期中的問題。而且，運行各種類型的開發人員測試，如組件測試、功能測試和性能測試，能夠在開發生命周期中更早地 將問題顯示出來。
 |
|
通常在持續集成（CI）環境中運行的開發人員測試有效地扮演著代碼質量聚光燈的角色。這是因為如果能有效地編寫這些測試，則幾乎能夠在問題（如缺陷）產生之時就將其發現。不經常運行測試通常就不怎么有效，因為從產生缺陷到發現該缺陷的時間相隔很長，但持續地（即，每一次代碼改變時）運行測試能確�？焖侔l現無意識的行為。
本文涵蓋下列內容：
- 通過 Ant 運行 JUnit 測試
- 使用 JUnit 和 DbUnit 執行更長時間的運行組件測試
- 使用 JUnitPerf 確定哪些方法花費時間過久而執行失敗
- 用 Selenium 運行基于 Web 的功能測試
- 用 Cobertura 訪問代碼覆蓋率
- 用 CruiseControl 進行持續測試
我提供一個關于不同類型開發人員測試的概覽，和一些可以添加到構建過程并使用 Continuous Integration 系統持續運行的例子。
|
|
有時，我聽到開發人員將開發人員測試這一術語與簡單的單元測試相混淆；然而，我發現將單元測試這一術語提練得更加明確很有幫助。對我來說，單元測試是快速運行的 測試，通常測試沒有大的外部依賴項（如數據庫）的單獨的類。例如，清單 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 構建的上下文中啟動這些相同的測試。
清單 2 是一個 Ant 腳本片段，介紹了執行一批單元測試的 junit 任務。這項任務與 JUnit 一起運作，其妙處在于：定義過的所有測試現在都能自動運行并且如果其中任何一個測試失敗，則構建也將失敗 —— 通過使用 haltonfailure 屬性實現。
清單 2. 在 Ant 中運行單元測試
<junit fork="yes" haltonfailure="true" dir="${basedir}" printsummary="yes"> <classpath refid="test.class.path" /> <classpath refid="project.class.path"/> <formatter type="plain" usefile="true" /> <formatter type="xml" usefile="true" /> <batchtest fork="yes" todir="${logs.junit.dir}"> <fileset dir="${test.unit.dir}"> <patternset refid="test.sources.pattern"/> </fileset> </batchtest></junit> |
注意：test.unit.dir 指定測試的位置。這是將這些測試（在本例中為單元測試）和其他測試隔離起來的有效方法。通過利用這項技術，可以通過定義另外的 Ant 目標來先運行較快的測試，接著運行較慢的測試（如組件測試、功能測試和系統測試）。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
