后退到測(cè)試類內(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);
}
}
后，我們可以重寫測(cè)試，以便被測(cè)試的對(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è)稍長(zhǎng)的測(cè)試，但該測(cè)試只關(guān)注正在測(cè)試的類的直接行為，而不是 ATM 接口之外整個(gè)系統(tǒng)的行為。也是說(shuō)，我們不再檢查測(cè)試帳戶的終余額是否正確；我們將在對(duì) Transaction 對(duì)象的單元測(cè)試中檢查該函數(shù)，而不是在對(duì) AtmGui 對(duì)象的單元測(cè)試中。
注：根據(jù)模仿對(duì)象的創(chuàng)造者所說(shuō)，它應(yīng)該在其 validate() 方法內(nèi)部執(zhí)行自己的所有驗(yàn)證。在本示例中，為了清晰起見(jiàn)，我們將驗(yàn)證的某些部分放在了測(cè)試方法內(nèi)部。隨著您更加熟練地使用模仿對(duì)象，對(duì)于將多少驗(yàn)證職責(zé)代理給模仿對(duì)象，您將會(huì)深有體會(huì)。
內(nèi)部類魔法
在清單 6 中，我們使用了 AtmGui 的匿名內(nèi)部子類來(lái)覆蓋 createTransaction 方法。因?yàn)槲覀冎恍枰采w一個(gè)簡(jiǎn)單的方法，所以這是實(shí)現(xiàn)我們目標(biāo)的簡(jiǎn)明方法。如果我們覆蓋多個(gè)方法或在許多測(cè)試之間共享 AtmGui 子類，那么創(chuàng)建一個(gè)完整的（非匿名）成員類是值得的。
我們還使用了實(shí)例變量來(lái)存儲(chǔ)對(duì)模仿對(duì)象的引用。這是在測(cè)試方法和特殊化類之間共享數(shù)據(jù)的簡(jiǎn)單方法。這是可以接受的，因?yàn)槲覀兊臏y(cè)試框架不是多線程的或可重入的。（如果它是多線程的或可重入的，則必須用 synchronized 塊保護(hù)我們自己。）
后，我們將模仿對(duì)象本身定義為測(cè)試類的專用內(nèi)部類 — 這通常是一種便利的方法，因?yàn)閷⒛７聦?duì)象放在使用它的測(cè)試代碼旁邊會(huì)更加清楚，又因?yàn)閮?nèi)部類有權(quán)訪問(wèn)包含它們的類的實(shí)例變量。
小心不出大錯(cuò)
因?yàn)槲覀兏采w了工廠方法來(lái)編寫這個(gè)測(cè)試，所以其結(jié)果是：我們的測(cè)試不再包括任何原始創(chuàng)建代碼（現(xiàn)在它在基類的工廠方法內(nèi)部）。添加確實(shí)包括該代碼的測(cè)試也許是有益的。這與調(diào)用基類的工廠方法并斷言返回對(duì)象具有正確類型一樣簡(jiǎn)單。例如：
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ì)象來(lái)著手這種方法，而不是用工廠方法 — 我們以前是這樣做的，但很快放棄了。
將第三種對(duì)象類型（角色）引入系統(tǒng)會(huì)有一些潛在的缺點(diǎn)：
它增加了復(fù)雜性，而沒(méi)有相應(yīng)地增加功能。
它會(huì)迫使您更改目標(biāo)對(duì)象的公用接口。如果必須傳入抽象工廠對(duì)象，那么您必須添加一個(gè)新的公用構(gòu)造函數(shù)或賦值（mutator）方法。
許多語(yǔ)言對(duì)于“工廠”這一概念都附有一些約定，它們會(huì)使您誤入歧途。例如，在 Java 語(yǔ)言中，工廠通常作為靜態(tài)方法實(shí)現(xiàn)；在這種情況下，這是不合適的。
請(qǐng)記住，本練習(xí)的宗旨是使對(duì)象更易于測(cè)試。通常，用于可測(cè)性的設(shè)計(jì)可以將對(duì)象的 API 推向一種更清晰更模塊化的狀態(tài)。但它會(huì)走得太遠(yuǎn)。測(cè)試驅(qū)動(dòng)的設(shè)計(jì)更改不應(yīng)該污染原始對(duì)象的公用接口。
在 ATM 示例中，對(duì)于產(chǎn)品代碼，AtmGui 對(duì)象始終只產(chǎn)生一種類型的 Transaction 對(duì)象（實(shí)際類型）。測(cè)試代碼希望它產(chǎn)生另一種類型的對(duì)象（模仿對(duì)象）。但強(qiáng)迫公用 API 適應(yīng)工廠對(duì)象或抽象工廠（只因?yàn)闇y(cè)試代碼要求它這樣）是錯(cuò)誤的設(shè)計(jì)。如果產(chǎn)品代碼無(wú)需實(shí)例化該合作者的多個(gè)類型，那么添加該功能將使終的設(shè)計(jì)不必要地變得難于理解。
參考資料
由 Tim Mackinnon、Steve Freeman 和 Philip Craig 合著的文章“Endo-Testing: Unit Testing with Mock Objects”介紹了術(shù)語(yǔ)模仿對(duì)象。
Mock Objects Project 是支持模仿對(duì)象實(shí)現(xiàn)的框架。
工廠方法和抽象工廠設(shè)計(jì)模式的來(lái)源是由 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 語(yǔ)言的單元測(cè)試框架。
請(qǐng)參考 Purple Technology 的 XP 和重構(gòu)參考資料列表。
由 XP 教練和 Java 開(kāi)發(fā)人員 Roy Miller 合著的專欄文章 Demystifying Extreme Programming 洞察了這個(gè)方法，其中，測(cè)試是關(guān)鍵組件。請(qǐng)務(wù)必訪問(wèn)一下附隨的論壇。
Nicholas Lesiecki 的“Test Flexibly with AspectJ and mock objects”（developerWorks，2002 年 5 月）詳細(xì)地描述了在單元測(cè)試時(shí)如何使用 AspectJ 和模仿對(duì)象。
由 Eric Allen 著的“Diagnosing Java code: Unit tests and automated code analysis working together”（developerWorks，2002 年 10 月）研究了單元測(cè)試和靜態(tài)分析之間的關(guān)系。
WebSphere 開(kāi)發(fā)者園地中“Application Quality Assurance: Unit Testing”一文研究了使用 JUnit 的單元測(cè)試。
WebSphere 開(kāi)發(fā)者園地中“Debugging and Unit-Testing Server-Side Web Applications”一文也描述了包括交互式調(diào)試和迭代單元測(cè)試的服務(wù)器端 Web 開(kāi)發(fā)的方案。
在 developerWorks Java 技術(shù)專區(qū)可找到數(shù)百篇有關(guān) Java 技術(shù)的文章和教程。
關(guān)于作者
Alexander Day Chaffee 是 Purple Technology 的創(chuàng)辦人，該公司提供了 Java 語(yǔ)言、極端編程和開(kāi)放源碼咨詢和培訓(xùn)。他管理 jGuru 的 Servlets FAQ。作為 EarthWeb 的軟件工程主管，Alex 與人共同創(chuàng)建了 Gamelan，這是 Java 社區(qū)的正式目錄。可以通過(guò) alex@jguru.com 與他聯(lián)系。
William Pietri 的父親是一位系統(tǒng)分析師和企業(yè)家，William 在十三歲時(shí)開(kāi)始利用計(jì)算機(jī)賺取午餐費(fèi)。從那以后，他幾乎從事過(guò)技術(shù)領(lǐng)域的各個(gè)方面，從技術(shù)支持到系統(tǒng)管理到軟件工程到用戶界面設(shè)計(jì)。他是 Scissor（技術(shù)咨詢公司）的創(chuàng)辦人。可以通過(guò) william@scissor.com 與 William 聯(lián)系。
