測試套件可以形象地分為三層，每一層代表一種不同的開發人員測試類型，該測試類型由其運行時間的長短決定。正如在圖 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() 方法并運行由它返回的所有測試。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
