1.簡介

　　在一篇早些的文章（請參見Test Infected: Programmers Love Writing Tests， Java Report， July 1998， Volume 3， Number 7）中，我們描述了如何使用一個簡單的框架來編寫可重復的測試。
在本文中我們將匆匆一瞥其內中細節(jié)，并向你展示該框架本身是如何被構造的。

　　我們細致地研究JUint框架并思索如何來構造它。我們發(fā)現(xiàn)了許多不同層次上的教訓。在本文中，我們將嘗試著立刻與它們進行溝通，這是一個令人絕望的任務，但至少它是在我們向你展示設計和構造一件價值被證實的軟件的上下文中來進行的。

　　我們引發(fā)了一個關于框架目標的討論。在對框架本身的表達期間，目標將重復出現(xiàn)許多小的細節(jié)中。此后，我們提出框架的設計和實現(xiàn)。設計將從模式（驚奇，驚奇）的角度進行描述，并作為優(yōu)美的程序來予以實現(xiàn)。我們總結了一些的關于框架開發(fā)的想法。

　　2.什么是JUnit的目標呢？

　　首先，我們不得不回到開發(fā)的假定上去。如果缺少一個程序特性的自動測試（automated test），我們便假定其無法工作。這看起來要比主流的假定更加安全，主流的假定認為如果開發(fā)者向我們保證一個程序特性能夠工作，那么現(xiàn)在和將來其都會永遠工作。

　　從這個觀點來看，當開發(fā)者編寫和調試代碼時，它們的工作并沒有完成，它們還要必須編寫測試來演示程序能夠工作。然而，每個人都太忙，他們要做的事情太多，他們沒有充足的時間用于測試。我已經(jīng)有太多的代碼需要編寫，要我如何再來編寫測試代碼？回答我，強硬的項目經(jīng)理先生。因此，首要目標是編寫一個框架，在這個框架中開發(fā)者能夠看到實際來編寫測試的希望之光。該框架必須要使用常見的工具，從而學習起來不會有太多的新東西。其不能比完全編寫一個新測試所必須的工作更多。必須排除重復性的工作。

　　如果所有測試都這樣去做的話，你將可以僅在一個調試器中編寫表達式來完成。然而，這對于測試而言尚不充分。告訴我你的程序現(xiàn)在能夠工作，對我而言并沒有什么幫助，因為它并沒有向我保證你的程序從我現(xiàn)在集成之后的每一分鐘都將會工作，以及它并沒有向我保證你的程序將依然能夠工作五年，那時你已經(jīng)離開了很長的時間。

　　于是，測試的第二個目標是生成可持續(xù)保持其價值的測試。除原作者以外的其他人必須能夠執(zhí)行測試并解釋其結果。應該能夠將不同作者的測試結合起來并在一起運行，而不必擔心相互沖突。

　　后，必須能夠以現(xiàn)有的測試作為支點來生成新的測試。生成一個裝置（setup）或夾具（fixture）是昂貴的，并且一個框架必須能夠對夾具進行重用，以運行不同的測試。哦，還有別的嗎？

　　3.JUnit的設計

　　JUnit的設計將以一種首次在Patterns Generate Architectures（請參見"Patterns Generate Architectures"， Kent Beck and Ralph Johnson， ECOOP 94）中使用的風格來呈現(xiàn)。其思想是通過從零開始來應用模式，然后一個接一個，直至你獲得系統(tǒng)架構的方式來講解一個系統(tǒng)的設計。我們將提出需要解決的架構問題，總結用來解決問題的模式，然后展示如何將模式應用于JUnit。

　　3.1 由此開始－TestCase

　　首先我們必須構建一個對象來表達我們的基本概念，TestCase（測試案例）。開發(fā)者經(jīng)常在頭腦中存在著測試案例，但在實現(xiàn)它們的時候卻采用了許多不同的方式－

　　· 打印語句

　　· 調試器表達式

　　· 測試腳本

　　如果我們想要輕松地操縱測試，必須將它們構建成對象。這將會獲取到一個僅僅是隱藏在開發(fā)者頭腦中的測試，并使之具體化，其支持我們創(chuàng)建測試的目標，即能夠持續(xù)地保持它們的價值。同時，對象的開發(fā)者比較習慣于使用對象來進行開發(fā)，因此將測試構建成對象的決定支持我們的目標－使測試的編寫更加吸引人（或至少是不太華麗）。

　　Command（命令）模式（請參見Gamma， E.， et al. Design Patterns: Elements of Reusable Object-Oriented Software， Addison-Wesley， Reading， MA， 1995）則能夠比較好地滿足我們的需求。摘引其意圖（intent），“將一個請求封裝成一個對象，從而使你可用不同的請求對客戶進行參數(shù)化；對請求進行排隊或記錄請求日志...”Command告訴我們可以為一個操作生成一個對象并給出它的一個“execute（執(zhí)行）”方法。以下代碼定義了TestCase類：

clearcase/" target="_blank" >cccccc width="90%" align=center bgColor=#e1e1e1 border=1>
public abstract class TestCase implements Test {
…
}

　　因為我們期望可以通過繼承來對該類進行重用，我們將其聲明為“public abstract”。暫時忽略其實現(xiàn)接口Test的事實。鑒于當前設計的需要，你可以將TestCase看作是一個孤立的類。

　　每一個TestCase在創(chuàng)建時都要有一個名稱，因此若一個測試失敗了，你便可識別出失敗的是哪個測試。

public abstract class TestCase implements Test {
　private final String fName;

　public TestCase(String name) {
　　fName= name;
　}

　public abstract void run();
　　…
}

　　為了闡述JUnit的演變過程，我們將使用圖（diagram）來展示構架的快照（snapshot）。我們使用的標記很簡單。其使用包含相關模式的尖方框來標注類。當類在模式中的角色（role）顯而易見時，則僅顯示模式的名稱。如果角色并不清晰，則在尖方框中增加與該類相關的參與者的名稱。該標記可使圖的混亂度降到小限度，并首次見諸于Applying Design Patterns in Java（請參見Gamma， E.， Applying Design Patterns in Java， in Java Gems， SIGS Reference Library， 1997）。圖1展示了這種應用于TestCase中的標記。由于我們是在處理一個單獨的類并且沒有不明確的地方，因此僅顯示模式的名稱。