1.簡介
在一篇早些的文章（請參見Test Infected: Programmers Love Writing Tests， Java Report， July 1998， Volume 3， Number 7）中，我們描述了如何使用一個簡單的框架來編寫可重復(fù)的測試。
在本文中我們將匆匆一瞥其內(nèi)中細(xì)節(jié)，并向你展示該框架本身是如何被構(gòu)造的。
我們細(xì)致地研究JUint框架并思索如何來構(gòu)造它。我們發(fā)現(xiàn)了許多不同層次上的教訓(xùn)。在本文中，我們將嘗試著立刻與它們進(jìn)行溝通，這是一個令人絕望的任務(wù)，但至少它是在我們向你展示設(shè)計和構(gòu)造一件價值被證實的軟件的上下文中來進(jìn)行的。
我們引發(fā)了一個關(guān)于框架目標(biāo)的討論。在對框架本身的表達(dá)期間，目標(biāo)將重復(fù)出現(xiàn)許多小的細(xì)節(jié)中。此后，我們提出框架的設(shè)計和實現(xiàn)。設(shè)計將從模式（驚奇，驚奇）的角度進(jìn)行描述，并作為優(yōu)美的程序來予以實現(xiàn)。我們總結(jié)了一些的關(guān)于框架開發(fā)的想法。
2.什么是JUnit的目標(biāo)呢？
首先，我們不得不回到開發(fā)的假定上去。如果缺少一個程序特性的自動測試（automated test），我們便假定其無法工作。這看起來要比主流的假定更加安全，主流的假定認(rèn)為如果開發(fā)者向我們保證一個程序特性能夠工作，那么現(xiàn)在和將來其都會永遠(yuǎn)工作。
從這個觀點來看，當(dāng)開發(fā)者編寫和調(diào)試代碼時，它們的工作并沒有完成，它們還要必須編寫測試來演示程序能夠工作。然而，每個人都太忙，他們要做的事情太多，他們沒有充足的時間用于測試。我已經(jīng)有太多的代碼需要編寫，要我如何再來編寫測試代碼？回答我，強硬的項目經(jīng)理先生。因此，首要目標(biāo)是編寫一個框架，在這個框架中開發(fā)者能夠看到實際來編寫測試的希望之光。該框架必須要使用常見的工具，從而學(xué)習(xí)起來不會有太多的新東西。其不能比完全編寫一個新測試所必須的工作更多。必須排除重復(fù)性的工作。
如果所有測試都這樣去做的話，你將可以僅在一個調(diào)試器中編寫表達(dá)式來完成。然而，這對于測試而言尚不充分。告訴我你的程序現(xiàn)在能夠工作，對我而言并沒有什么幫助，因為它并沒有向我保證你的程序從我現(xiàn)在集成之后的每一分鐘都將會工作，以及它并沒有向我保證你的程序?qū)⒁廊荒軌蚬ぷ魑迥辏菚r你已經(jīng)離開了很長的時間。
于是，測試的第二個目標(biāo)是生成可持續(xù)保持其價值的測試。除原作者以外的其他人必須能夠執(zhí)行測試并解釋其結(jié)果。應(yīng)該能夠?qū)⒉煌髡叩臏y試結(jié)合起來并在一起運行，而不必?fù)?dān)心相互沖突。
后，必須能夠以現(xiàn)有的測試作為支點來生成新的測試。生成一個裝置（setup）或夾具（fixture）是昂貴的，并且一個框架必須能夠?qū)A具進(jìn)行重用，以運行不同的測試。哦，還有別的嗎？
3.JUnit的設(shè)計
JUnit的設(shè)計將以一種首次在Patterns Generate Architectures（請參見"Patterns Generate Architectures"， Kent Beck and Ralph Johnson， ECOOP 94）中使用的風(fēng)格來呈現(xiàn)。其思想是通過從零開始來應(yīng)用模式，然后一個接一個，直至你獲得系統(tǒng)架構(gòu)的方式來講解一個系統(tǒng)的設(shè)計。我們將提出需要解決的架構(gòu)問題，總結(jié)用來解決問題的模式，然后展示如何將模式應(yīng)用于JUnit。
3.1 由此開始－TestCase
首先我們必須構(gòu)建一個對象來表達(dá)我們的基本概念，TestCase（測試案例）。開發(fā)者經(jīng)常在頭腦中存在著測試案例，但在實現(xiàn)它們的時候卻采用了許多不同的方式－
· 打印語句
· 調(diào)試器表達(dá)式
· 測試腳本
如果我們想要輕松地操縱測試，必須將它們構(gòu)建成對象。這將會獲取到一個僅僅是隱藏在開發(fā)者頭腦中的測試，并使之具體化，其支持我們創(chuàng)建測試的目標(biāo)，即能夠持續(xù)地保持它們的價值。同時，對象的開發(fā)者比較習(xí)慣于使用對象來進(jìn)行開發(fā)，因此將測試構(gòu)建成對象的決定支持我們的目標(biāo)－使測試的編寫更加吸引人（或至少是不太華麗）。
Command（命令）模式（請參見Gamma， E.， et al. Design Patterns: Elements of Reusable Object-Oriented Software， Addison-Wesley， Reading， MA， 1995）則能夠比較好地滿足我們的需求。摘引其意圖（intent），“將一個請求封裝成一個對象，從而使你可用不同的請求對客戶進(jìn)行參數(shù)化；對請求進(jìn)行排隊或記錄請求日志...”Command告訴我們可以為一個操作生成一個對象并給出它的一個“execute（執(zhí)行）”方法。以下代碼定義了TestCase類：
clearcase/" target="_blank" >cccccc width="90%" align=center bgColor=#e1e1e1 border=1>
public abstract class TestCase implements Test {
…
}
因為我們期望可以通過繼承來對該類進(jìn)行重用，我們將其聲明為“public abstract”。暫時忽略其實現(xiàn)接口Test的事實。鑒于當(dāng)前設(shè)計的需要，你可以將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）來展示構(gòu)架的快照（snapshot）。我們使用的標(biāo)記很簡單。其使用包含相關(guān)模式的尖方框來標(biāo)注類。當(dāng)類在模式中的角色（role）顯而易見時，則僅顯示模式的名稱。如果角色并不清晰，則在尖方框中增加與該類相關(guān)的參與者的名稱。該標(biāo)記可使圖的混亂度降到小限度，并首次見諸于Applying Design Patterns in Java（請參見Gamma， E.， Applying Design Patterns in Java， in Java Gems， SIGS Reference Library， 1997）。圖1展示了這種應(yīng)用于TestCase中的標(biāo)記。由于我們是在處理一個單獨的類并且沒有不明確的地方，因此僅顯示模式的名稱。
