后退到測試類內(nèi)部，我們將 MockTransaction 類定義為成員類，如清單 5 中所示：

清單 5. 將 MockTransaction 定義為成員類：

private MockTransaction extends Transaction {
    private boolean processCalled = false;
    // override process method so that no real work is done
    public void process() {
      processCalled = true;
      setStatus(Status.SUCCESS);
    }
    public void validate() {
      assertTrue(processCalled);
    }
  }
 

后，我們可以重寫測試，以便被測試的對(duì)象使用 MockTransaction 類，而不是使用實(shí)際類，如清單 6 中所示：

清單 6. 使用 MockTransaction 類

MockTransaction mockTransaction;
  public void testCheckingWithdrawal() {
    mockTransaction = new MockTransaction();
    AtmGui atm = new AtmGui() {
        protected Transaction createTransaction() {
          return mockTransaction;
        }
    };
    insertCardAndInputPin(atm);
    atm.pressButton("Withdraw");
    atm.pressButton("Checking");
    atm.pressButtons("1"， "0"， "0"， "0"， "0");
    assertContains("$100.00"， atm.getDisplayContents());
    atm.pressButton("Continue");
    assertEquals(100.00， mockTransaction.getAmount());
    assertEquals(TEST_CHECKING_ACCOUNT，
mockTransaction.getSourceAccount());
    assertEquals(TEST_CASH_ACCOUNT，
mockTransaction.getDestAccount());
    mockTransaction.validate();
}
 

該解決方案產(chǎn)生了一個(gè)稍長的測試，但該測試只關(guān)注正在測試的類的直接行為，而不是 ATM 接口之外整個(gè)系統(tǒng)的行為。也是說，我們不再檢查測試帳戶的終余額是否正確；我們將在對(duì) Transaction 對(duì)象的單元測試中檢查該函數(shù)，而不是在對(duì) AtmGui 對(duì)象的單元測試中。

注：根據(jù)模仿對(duì)象的創(chuàng)造者所說，它應(yīng)該在其 validate() 方法內(nèi)部執(zhí)行自己的所有驗(yàn)證。在本示例中，為了清晰起見，我們將驗(yàn)證的某些部分放在了測試方法內(nèi)部。隨著您更加熟練地使用模仿對(duì)象，對(duì)于將多少驗(yàn)證職責(zé)代理給模仿對(duì)象，您將會(huì)深有體會(huì)。

內(nèi)部類魔法

在清單 6 中，我們使用了 AtmGui 的匿名內(nèi)部子類來覆蓋 createTransaction 方法。因?yàn)槲覀冎恍枰�覆蓋一個(gè)簡單的方法，所以這是實(shí)現(xiàn)我們目標(biāo)的簡明方法。如果我們覆蓋多個(gè)方法或在許多測試之間共享 AtmGui 子類，那么創(chuàng)建一個(gè)完整的（非匿名）成員類是值得的。

我們還使用了實(shí)例變量來存儲(chǔ)對(duì)模仿對(duì)象的引用。這是在測試方法和特殊化類之間共享數(shù)據(jù)的簡單方法。這是可以接受的，因?yàn)槲覀兊臏y試框架不是多線程的或可重入的。（如果它是多線程的或可重入的，則必須用 synchronized 塊保護(hù)我們自己。）

后，我們將模仿對(duì)象本身定義為測試類的專用內(nèi)部類 — 這通常是一種便利的方法，因?yàn)閷⒛７聦?duì)象放在使用它的測試代碼旁邊會(huì)更加清楚，又因?yàn)閮?nèi)部類有權(quán)訪問包含它們的類的實(shí)例變量。

小心不出大錯(cuò)

因?yàn)槲覀兏采w了工廠方法來編寫這個(gè)測試，所以其結(jié)果是：我們的測試不再包括任何原始創(chuàng)建代碼（現(xiàn)在它在基類的工廠方法內(nèi)部）。添加確實(shí)包括該代碼的測試也許是有益的。這與調(diào)用基類的工廠方法并斷言返回對(duì)象具有正確類型一樣簡單。例如：

AtmGui atm = new AtmGui();
    Transaction t = atm.createTransaction();
    assertTrue(!(t instanceof MockTransaction));
 
注：相反，assertTrue(t instanceof Transaction) 不能滿足，因?yàn)?MockTransaction 也是 Transaction。

從工廠方法到抽象工廠

此時(shí)，您可能很想更進(jìn)一步并用成熟的抽象工廠對(duì)象替換工廠方法，如 Erich Gamma 等人在設(shè)計(jì)模式中詳細(xì)描述的那樣。（請(qǐng)參閱參考資料）。實(shí)際上，許多人已經(jīng)用工廠對(duì)象來著手這種方法，而不是用工廠方法 — 我們以前是這樣做的，但很快放棄了。

將第三種對(duì)象類型（角色）引入系統(tǒng)會(huì)有一些潛在的缺點(diǎn)：

它增加了復(fù)雜性，而沒有相應(yīng)地增加功能。

它會(huì)迫使您更改目標(biāo)對(duì)象的公用接口。如果必須傳入抽象工廠對(duì)象，那么您必須添加一個(gè)新的公用構(gòu)造函數(shù)或賦值（mutator）方法。

許多語言對(duì)于“工廠”這一概念都附有一些約定，它們會(huì)使您誤入歧途。例如，在 Java 語言中，工廠通常作為靜態(tài)方法實(shí)現(xiàn)；在這種情況下，這是不合適的。

請(qǐng)記住，本練習(xí)的宗旨是使對(duì)象更易于測試。通常，用于可測性的設(shè)計(jì)可以將對(duì)象的 API 推向一種更清晰更模塊化的狀態(tài)。但它會(huì)走得太遠(yuǎn)。測試驅(qū)動(dòng)的設(shè)計(jì)更改不應(yīng)該污染原始對(duì)象的公用接口。

在 ATM 示例中，對(duì)于產(chǎn)品代碼，AtmGui 對(duì)象始終只產(chǎn)生一種類型的 Transaction 對(duì)象（實(shí)際類型）。測試代碼希望它產(chǎn)生另一種類型的對(duì)象（模仿對(duì)象）。但強(qiáng)迫公用 API 適應(yīng)工廠對(duì)象或抽象工廠（只因?yàn)闇y試代碼要求它這樣）是錯(cuò)誤的設(shè)計(jì)。如果產(chǎn)品代碼無需實(shí)例化該合作者的多個(gè)類型，那么添加該功能將使終的設(shè)計(jì)不必要地變得難于理解。

參考資料

由 Tim Mackinnon、Steve Freeman 和 Philip Craig 合著的文章“Endo-Testing: Unit Testing with Mock Objects”介紹了術(shù)語模仿對(duì)象。

Mock Objects Project 是支持模仿對(duì)象實(shí)現(xiàn)的框架。

工廠方法和抽象工廠設(shè)計(jì)模式的來源是由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides（也稱為四人組（Gang of Four））合著的 Design Patterns: Elements of Reusable Object-Oriented Software（Addison-Wesley，1997 年）。

如果您不熟悉設(shè)計(jì)模式，那么您還需要學(xué)習(xí)這個(gè)由兩部分組成的免費(fèi)教程：

Java design patterns 101（developerWorks，2002 年 1 月）介紹了模式。

Java design patterns 201（developerWorks，2002 年 4 月）介紹了四人組未描述到的其它模式。

請(qǐng)閱讀在線文章 The Factory Method Design Pattern。

由 Martin Fowler 維護(hù)的 Refactoring Home Page 是程序員的主要參考資料。

另外，由 Martin Fowler 編寫的 Refactoring: Improving the Design of Existing Code（Addison-Wesley，1999 年）值得一讀。

JUnit 是流行的 Java 語言的單元測試框架。

請(qǐng)參考 Purple Technology 的 XP 和重構(gòu)參考資料列表。

由 XP 教練和 Java 開發(fā)人員 Roy Miller 合著的專欄文章 Demystifying Extreme Programming 洞察了這個(gè)方法，其中，測試是關(guān)鍵組件。請(qǐng)務(wù)必訪問一下附隨的論壇。

Nicholas Lesiecki 的“Test Flexibly with AspectJ and mock objects”（developerWorks，2002 年 5 月）詳細(xì)地描述了在單元測試時(shí)如何使用 AspectJ 和模仿對(duì)象。

由 Eric Allen 著的“Diagnosing Java code: Unit tests and automated code analysis working together”（developerWorks，2002 年 10 月）研究了單元測試和靜態(tài)分析之間的關(guān)系。

WebSphere 開發(fā)者園地中“Application Quality Assurance: Unit Testing”一文研究了使用 JUnit 的單元測試。

WebSphere 開發(fā)者園地中“Debugging and Unit-Testing Server-Side Web Applications”一文也描述了包括交互式調(diào)試和迭代單元測試的服務(wù)器端 Web 開發(fā)的方案。

在 developerWorks Java 技術(shù)專區(qū)可找到數(shù)百篇有關(guān) Java 技術(shù)的文章和教程。

關(guān)于作者

Alexander Day Chaffee 是 Purple Technology 的創(chuàng)辦人，該公司提供了 Java 語言、極端編程和開放源碼咨詢和培訓(xùn)。他管理 jGuru 的 Servlets FAQ。作為 EarthWeb 的軟件工程主管，Alex 與人共同創(chuàng)建了 Gamelan，這是 Java 社區(qū)的正式目錄�？梢酝ㄟ^ alex@jguru.com 與他聯(lián)系。

William Pietri 的父親是一位系統(tǒng)分析師和企業(yè)家，William 在十三歲時(shí)開始利用計(jì)算機(jī)賺取午餐費(fèi)。從那以后，他幾乎從事過技術(shù)領(lǐng)域的各個(gè)方面，從技術(shù)支持到系統(tǒng)管理到軟件工程到用戶界面設(shè)計(jì)。他是 Scissor（技術(shù)咨詢公司）的創(chuàng)辦人�？梢酝ㄟ^ william@scissor.com 與 William 聯(lián)系。