本文內容包括:
人人都認可開發人員測試的重要性，但為什么運行測試還是需要花費太多時間？本月，Andrew Glover 揭示了三種用來確保端到端系統健壯性的測試類型，隨后展示了如何按類型來自動排序及運行測試。即使是使用當今大型測試套件，這樣做也能顯著地減少構建時間。
如果這樣說不會（令您）很痛苦的話，請設想您是一名任職于一家 2002 年早期創建的公司的開發人員。在金錢的驅動下，您和您的團隊接到了一項任務，即使用最新且最強大的 Java? API 構建一個大型的數據驅動的 Web 應用程序。您和公司管理層都堅定不疑地相信這就是最終將被稱為敏捷過程 的東西。從第一天起，您就用 JUnit 構建測試，且把它作為 Ant 構建過程的一部分盡可能頻繁地運行。還將設置一個定時任務在夜間運行構建。在接下來的某個時刻，有人會下載 CruiseControl，不斷增長的測試套件會在每次簽入時運行。
時至今日
經過過去幾年的努力，您的公司已經開發了一個龐大的代碼庫和一個同樣龐大的 JUnit 測試套件。一切都很正常，直到大約一年前，測試套件包含了 2000 個測試，同時人們開始注意到運行構建過程用時超過三個小時。在此之前的幾個月，由于 CI 服務器資源緊張，您在代碼簽入時通過 Continuous Integration（CI）停止運行單元測試，并將測試切換到夜間運行，這使得之后的早晨時間非常緊張，于是開發人員努力去弄清楚是什么出錯以及為什么出錯。
這些天，似乎測試套件整晚極少超過一次運行，為什么會這樣呢？因為它們費時太多！沒人會僅僅為了弄明白系統是否運行良好而幾個小時守在那里。此外，整個測試套件都是在晚上運行，不是嗎？
由于測試運行得太不頻繁，它們常常充滿了錯誤。因而，您和您的團隊開始質疑單元測試的價值：如果它們對代碼質量那么重要，那又為什么會讓人這么頭痛呢？你們的結論是：單元測試有其重要的作用，但必須要能用一種更為敏捷的方式運行它們。
您所需要的是一個將構建轉換到一種更為敏捷狀態的策略。您需要這樣一種解決方案，使一天當中運行測試的次數超過一次，并使測試套件恢復到要用三個小時才能完成構建之前的水平。
為完整地恢復整個測試套件，在試圖提出一個策略之前，很有必要弄清楚通用術語 “單元測試” 的含義。諸如 “我家有一個動物” 和 “我喜歡車” 這樣的表述并不很具體，“我們編寫單元測試” 也是一樣。這年頭，單元測試能代表一切。
就拿之前有關動物和車的表述來說：它們導致了更多的疑問。例如，您家有哪種動物？是一只貓、一條蜥蜴還是一頭熊？“我家有一頭熊” 和 “我家有一只貓” 截然不同。同樣，當和汽車銷售員交談時，只說 “我喜歡車” 沒什么用處。您喜歡哪種車：賽車、卡車還是旅行車？任何一個答案都能帶來截然不同的結果。
同樣，對于開發人員測試來說，按照類型 將測試分類也是很有用的。這樣做能夠實現更為精確的語言，并且能使您的團隊以不同的頻率運行不同的測試類型。為了避免運行所有 “單元測試” 所需的令人恐懼的三小時構建時間，分類是關鍵。
測試套件可以形象地分為三層，每一層代表一種不同的開發人員測試類型，該測試類型由其運行時間的長短決定。正如在圖 1 中看到的那樣，每一層都增加了總的構建時間，要么增加了運行時間，要么最終增加了編寫時間。
圖 1.測試分類的三個層次
底層由運行時間最短的測試構成，可以想象的到，它們也最易于編寫。這些測試占用的代碼量也是最少的。頂層由更高級別的測試構成，這些測試占用了應用程序更大的部分。這些測試有一點難于編寫，執行時間也要長得多。中間層是處于這兩個極端中間的測試類型。
三種類型如下所示：
- 單元測試
- 組件測試
- 系統測試
讓我們分別來看一下。
單元測試隔離地 驗證一個或多個對象。單元測試不處理數據庫、文件系統或任何可能延長測試運行時間的內容；因而，從第一天就可以編寫單元測試。事實上，這也正是 JUnit 設計的確切目的所在。單元測試的隔離概念有無數的模擬對象庫作后盾，這些庫便利了將一個特定的對象從其外部依賴項中隔離出來。而且，單元測試能夠在真正要測試的代碼前編寫 —— 由此有了測試優先開發 的概念。
單元測試通常易于編寫，因為它們并不依靠于架構的依賴項，且通常運行得很快。缺點是，獨立的單元測試只能覆蓋稍顯有限的代碼。單元測試的重大價值在于：它們使開發人員能夠在盡可能低的層面上保證對象的可靠性。
由于單元測試運行得如此之快且如此易于編寫，代碼庫中應包含許多單元測試，并且應該盡可能多地運行它們。在執行構建時，應該經常 運行它們，不管是在機器上，還是在 CI 環境的上下文中（這意味著，代碼一經簽入 SCM 環境，就要運行單元測試）。
組件測試驗證多個相互作用的對象，但它突破了隔離的概念。由于組件測試處理一個架構的多個層次，所以它們經常用于處理數據庫、文件系統、網絡元素等。同樣，提前編寫組件測試有點難，所以將其包含至一個真正的測試優先/測試驅動的場景中是很大的挑戰。
編寫組件測試要花更長的時間，因為它們比單元測試所涉及的東西要多。另一方面，由于其寬廣的范圍，它們實現了比單元測試更廣的代碼覆蓋率。當然它們也要花更多時間運行，所以同時運行很多的組件測試會顯著地 增加總的測試時間。
許多框架有助于測試大型架構組件。DbUnit 是這類框架的一個典型例子。DbUnit 能夠很好地處理在測試狀態間建立一個數據庫這樣的復雜性，因而它會使編寫依賴于數據庫的測試變得較為簡單。
當構建的測試延長時，通常都預示著包含了一個大型的組件測試套件。由于這些測試比真正的單元測試運行時間長，因而不能一直運行它們。相應地，在 CI 環境中這些測試可以至少 每小時運行一次。在簽入任何代碼前，也應該總在一個本地開發人員機器上運行這些測試。
系統測試端到端地 驗證一個軟件應用程序。因而，它們引入了一個更高級別的架構復雜度：整個應用程序必需為要進行的系統測試而運行。如果是一個 Web 應用程序，您就需要訪問數據庫以及 Web 服務器、容器和任何與運行系統測試相關的配置。其遵循這樣的原則，即大多數系統測試都在軟件生命周期的較后周期中編寫。
編寫系統測試是個挑戰，也需要大量的時間來實際地執行。而另一方面，就架構性代碼覆蓋率來講，系統測試是一件極為劃算的事情。
系統測試和功能測試很相似。所不同的是，它們并不仿效用戶，而是模擬出 一個用戶。與在組件測試中一樣，現在創建了大量的框架來為這些測試提供方便。例如，jWebUnit 通過模擬一個瀏覽器來測試 Web 應用程序。
實現測試分類
所以，您的單元測試套件就是名副其實的包括單元測試、組件測試和系統測試的套件。不僅如此，在檢查了這些測試后，您現在知道構建花了三個小時的原因是：絕大部分時間都被組件測試所占用。下一個問題是，如何用 JUnit 實現測試分類？
有幾種方式可選，但這里我們只關注于其中兩種最簡單的方式：
- 根據所需種類創建定制的 JUnit 套件文件。
- 為每種測試類型創建定制目錄。
可以使用 JUnit 的 TestSuite 類（屬于 Test 類型）來定義許多互相歸屬的測試。首先，創建一個 TestSuite 實例，并為其添加相應的測試類或測試方法。然后，可以通過定義一個叫做 suite() 的 public static 方法，在 TestSuite 實例中指定 JUnit。包含的所有測試隨后將在單個運行中執行。因而，可以通過創建單元 TestSuite、組件 TestSuite 和系統 TestSuite 來實現測試分類。
例如，清單 1 中顯示的類創建了一個 TestSuite，其持有 suite() 方法中所有的組件測試。請注意此類并不是非常特定于 JUnit 的。它既沒有擴展 TestCase，也沒有定義任何測試用例。但它會反射性地找到 suite() 方法并運行由它返回的所有測試。
清單 1. 用于組件測試的 TestSuite
|
package test.org.acme.widget; import junit.framework.Test; public class ComponentTestSuite { public static void main(String[] args) { public static Test suite(){ |
定義 TestSuite 的過程的確需要瀏覽現有的測試，并將它們添加到相應的類中（即，將所有的單元測試添加到一個 UnitTestSuite 中）。這也意味著，由于在一個給定分類中編寫新測試，不得不將它們按照一定的程序添加到適當的 TestSuite 中，當然，還需要重新編譯 它們。
運行獨立的 TestSuites，然后試著創建單一的 Ant 任務，Ant 任務調用正確的測試集�？梢远x一個 component-test 任務，用于組織 ComponentTestSuite 等，正如清單 2 中所示：
清單 2. 只運行組件測試的 Ant 任務
| <target name="component-test" if="Junit.present" depends="junit-present,compile-tests"> <mkdir dir="${testreportdir}"/> <junit dir="./" failureproperty="test.failure" printSummary="yes" fork="true" haltonerror="true"> <sysproperty key="basedir" value="."/> <formatter type="xml"/> <formatter usefile="false" type="plain"/> <classpath> <path refid="build.classpath"/> <pathelement path="${testclassesdir}"/> <pathelement path="${classesdir}"/> </classpath> <batchtest todir="${testreportdir}"> <fileset dir="test"> <include name="**/ComponentTestSuite.java"/> </fileset> </batchtest> </junit> </target> |
理想情況下，還需要有調用單元測試和系統測試的任務。最后，在想要運行整個測試套件時，應該創建一個依賴于所有三種測試種類的第四項任務，如清單 3 中如示：
清單 3. 用于所有測試的 Ant 任務
| <target name="test-all" depends="unit-test,component-test,system-test"/> |
創建定制 TestSuite 是實現測試分類的一個快速解決方案。這個方法的缺點是：一旦創建新測試，就必須通過編程將它們添加到適當的 TestSuite 中，這很痛苦。為每種測試創建定制目錄更具擴展性，且允許不 經過重新編譯就添加新的經過分類的測試。
我發現，用 JUnit 實現測試分類最簡單的方法是將測試在邏輯上劃分為與其測試類型相應的特定目錄。使用這項技術，所有的單元測試將駐留在一個 unit 目錄中，所有的組件測試將駐留在一個 component 目錄中，依此類推。
例如，在一個保存所有未分類測試的 test 目錄中，可以創建三個新的子目錄，如清單 4 所示：
清單 4. 實現測試分類的目錄結構
| acme-proj/ test/ unit/ component/ system/ conf/ |
為運行這些測試，必需至少定義四個 Ant 任務：為單元測試定義一個，為組件測試定義一個，依此類推。第 4 項任務是一個方便的任務，它運行所有三種測試類型（如 清單 3 所示）。
該 JUnit 任務和 清單 2 中定義的任務非常相似。所不同的是該任務 batchtest 方面的一個細節。此時，fileset 指向一個具體的目錄。在清單 5 的例子中，它指向 unit 目錄。
清單 5. 用于運行所有單元測試的 JUnit 任務的批量測試方面
| <batchtest todir="${testreportdir}"> <fileset dir="test/unit"> <include name="**/**Test.java"/> </fileset> </batchtest> |
請注意，這個測試只運行 test/unit 目錄下的所有測試。當創建了新的單元測試（或針對此問題的任何其他測試），只需要將它們放到該目錄下，一切就準備妥當了！比起需要將一行新代碼添加到 TestSuite 文件并進行重新編譯，這樣還是多少簡單了一點。
回到最初的場景中，假設您和您的團隊認為使用特定目錄是針對構建時間問題的最具擴展性的解決方案。該任務最困難的地方是檢查及分配測試類型。您重構了 Ant 構建文件并創建了 4 項新任務（為單個的測試類型創建了三項，為運行所有這些測試類型創建了一項）。不僅如此，您還修改了 CruiseControl，從而只在（代碼）簽入時運行真正的單元測試，并以小時為基礎運行組件測試。在進一步檢查之后，發現系統測試也可以按小時運行，所以您創建了一個將組件測試和系統測試一起運行的額外任務。
最終結果是，測試每天都運行很多次，您的團隊能夠更快地發現集成錯誤 —— 通常在幾個小時之內。
當然，創建敏捷性構建并未解決全部問題，但它在確保代碼質量方面確實扮演了至關重要的角色。測試運行得更加頻繁了，針對開發人員測試價值的顧慮成為一段遙遠的記憶。另外，更重要的是，現在 2006 年您的公司獲得了極大的成功！
- 您可以參閱本文在 developerWorks 全球站點上的 英文原文 。
- “用 Selenium 自動化驗收測試” （Christian Hellsten，developerWorks，2005 年 12 月）：架構師、開發人員和測試人員可以在這里學到如何使用 Selenium 測試工具來自動化驗收測試。
- “Effective Unit Testing with DbUnit” （Andrew Glover，OnJava，2004 年 1 月）：介紹了用 DbUnit 進行的數據庫依賴性測試。
- “JUnit 4 搶先看” （Elliotte Harold，developerWorks，2005 年 9 月）： 執著的代碼測試員 Elliotte Harold 簡要地介紹了 JUnit 4。
- “追求代碼質量: 可重復的系統測試” （Andrew Glover，developerWorks，2006 年 9 月）：Andrew Glover 介紹了 Cargo，一個開放源碼框架，該框架以一種通用的風格自動化容器管理。
- “為 Web 應用程序創建測試用例” （Amit Tuli，developerWorks，2005 年 5 月）：軟件工程師 Amit Tuli 介紹了 jWebUnit。
- “ 追求代碼質量: JUnit 4 與 TestNG 的對比” （Andrew Glover，developerWorks，2006 年 4 月）：在 JUnit 4 面前，TestNG 是否已經過時？在這里找出否定的理由。
- 追求代碼質量 系列 （Andrew Glover，developerWorks）：獲得更多有關代碼語法、測試框架以及編寫專注于質量的代碼的信息。
- developerWorks：數百篇關于 Java 編程各個方面的文章。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
