后退到測(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)閷⒛7聦?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)系。