診斷 Java 代碼：設(shè)計“可測試的”應(yīng)用程序

2019-11-18 12:11:09

字體：大中小

供稿：網(wǎng)友

　　在診斷 java 代碼的這一部分中，Eric Allen 暫停了對具體錯誤模式的討論，轉(zhuǎn)而選擇討論關(guān)于設(shè)計易于、甚至我們樂于測試的軟件的問題。他概述了七條設(shè)計原則，這些原則能大幅提高您編寫測試代碼的效率并因此提高結(jié)果代碼庫的健壯性。請在討論論壇與作者和其它讀者共享您關(guān)于本文的心得。
　　謹以本文獻給周二攻擊的受害者，向災(zāi)難挑戰(zhàn)的英雄們和美國人民的鋼鐵意志。
　　當設(shè)計大型程序的時候，您必須時刻留心不同設(shè)計選項對諸如性能和可擴展性這樣的特征的影響。隨著軟件產(chǎn)品的日漸復(fù)雜及其無所不在的部署，軟件的“可測試性”也成了更重要的考慮事項。
　　
　　徹底測試代碼的重要性是顯然的。花在編寫測試和測試代碼上的時間和精力給您帶來的回報是維護成本的大幅降低。
　　
　　然而，除非您很小心，否則您花在測試代碼上的精力可能會首先達到花在編寫代碼上的精力的幾倍！我曾看到程序員們齊心協(xié)力地對他們的全部代碼進行單元測試，結(jié)果花在上面的時間使大多數(shù)人都以沮喪而告終。
　　
　　幸運的是，沒有必要這樣。在您設(shè)計軟件的時候應(yīng)用一些基本原則，編寫易于測試、甚至使測試成為樂趣的代碼是可能的。
　　
　　跟其它編碼原則一樣，這些原則也不是不容置疑或不可改變的教條。有時候打破這些規(guī)則也是必要的。因此，理解每條原則背后的動機和判定何時這些動機不適用（或應(yīng)讓位給更關(guān)心的問題）的能力是很重要的。
　　
　　原則 1. 到 GUI 視圖的外面去
　　盡可能把代碼移到 GUI 視圖的外面。然后各種 GUI 動作就能成了模型上的簡單方法調(diào)用。為什么您需要這樣做呢？
　　
　　對 GUI 測試者來說，通過方法調(diào)用測試功能比間接地測試功能輕易的多。
　　另一個好處是它使修改程序功能而不影響視圖變的更輕易。
　　當然，視圖中也可能存在錯誤。在理想情況下，對程序的測試將同時檢查模型和視圖。（想更多了解測試視圖，請參閱我關(guān)于 Liar View 錯誤模式的文章或 Jeffries 等人的 Extreme PRogramming Installed。這兩個鏈接都在參考資料部分。）
　　
　　原則 2. 使用類型進行錯誤檢查
　　類型是您的朋友 — 盡可能多地用類型系統(tǒng)自動檢查錯誤。
　　
　　類型能在程序運行之前自動捕捉程序中的錯誤。沒有靜態(tài)類型檢查的話，類型錯誤將作為破壞者逗留在您的程序中，直到恰當?shù)膱?zhí)行路徑碰巧把它揭露出來為止。
　　
　　最大限度地發(fā)揮使用類型的優(yōu)點是棘手的。通常，一組數(shù)據(jù)結(jié)構(gòu)可以在一個抽象級別上一起使用，或者被分出，成為一個單一的、更高抽象級別的一個新的相關(guān)數(shù)據(jù)類型。
　　
　　事實上，編程語言自身的歷史可以看成是可以編程的抽象級別的逐漸提高。匯編語言提供了比特到整數(shù)和浮點數(shù)的抽象。接下來是記錄和函數(shù)抽象，然后又是諸如對象、類、線程以及異常這樣的抽象。
　　
　　在每一抽象級別上，達到與更高級別抽象一致的功能是可能的，但那實質(zhì)上僅僅是耗費更多精力，冒更多的錯誤風(fēng)險。
　　
　　在面向?qū)ο笳Z言（其它現(xiàn)代語言也一樣）中，一個程序員在設(shè)計抽象上有很大的靈活性。在哪個抽象級別上設(shè)計程序就成了基于折衷的決定，比如由抽象級別提供的更多的健壯性和由于不能在更低抽象級別上工作而帶來的表達性（有時是性能）的損失。
　　
　　通常，高級別抽象帶來的健壯性和簡單性的價值很少被其它考慮事項超過。（要了解對這個問題的更多討論，請參閱我關(guān)于 Impostor Type 錯誤模式的文章，在參考資料部分有它的鏈接。）
　　
　　原則 3. 使用調(diào)節(jié)器避免“故障線路”（fault line）
　　我用“故障線路”來指獨立組件之間的接口，獨立組件之間和組件與其相應(yīng)子組件之間相比，很少有交互。這種故障線路的一個典型示例是 GUI 視圖和它的模型之間的接口。其它示例包括在編譯器中處理的不同階段之間的接口或操作系統(tǒng)的內(nèi)核和用戶界面之間的接口。
　　
　　找出程序的故障線路，然后用具有轉(zhuǎn)發(fā)功能的調(diào)節(jié)器快速訪問聚合組件。
　　
　　沿著故障線路隔離測試每個組件通常更輕易。但假如每個組件暴露的對象有很多，或者組件中您想測試的一些對象只有通過多個嵌套引用才能訪問，那么測試就會變的很乏味。
　　
　　不用隔離測試，而是擁有您在它上面調(diào)用您想測試的各種方法的單個調(diào)節(jié)器對象通常是有幫助的。這個對象然后能把這些方法調(diào)用轉(zhuǎn)發(fā)到適當?shù)牡胤健?br />　　
　　沿著相同線路，設(shè)計和自己的測試代碼串聯(lián)在一起的程序組件接口是有益的。這將使您把注重力集中在使這些接口盡可能簡單上。
　　
　　原則 4. 方法：小型簽名和缺省參數(shù)
　　使用小型方法說明和重載帶缺省方法參數(shù)的方法將使您在測試中調(diào)用這些方法變的愉快的多。否則，在測試這些方法時您將不得不構(gòu)造額外參數(shù)。假如參數(shù)很大，那么將很快導(dǎo)致代碼膨脹。更糟的是，它會誘使您編寫比在其它情況下更少的測試。
　　
　　原則 5. 訪問器不應(yīng)修改內(nèi)存狀態(tài)
　　請在您的測試中使用不修改內(nèi)存狀態(tài)的訪問器來檢查對象狀態(tài)。
　　
　　在某些方面，測試和實驗室試驗相似。它們都想證實特定假設(shè)有效。假如特定檢查動作改變了該領(lǐng)域的狀態(tài)，那么要這樣做會變得困難的多。
　　
　　與量子力學(xué)領(lǐng)域不同，計算機進程的狀態(tài)可以不修改就被檢查。使用這種原則對您有好處。
　　
　　原則 6. 用接口說明外部程序組件
　　用接口說明外部程序組件使得我們可以輕易地在測試案例中模擬這些組件。
　　
　　這條原則能節(jié)省大量時間，非凡是當外部組件的實現(xiàn)還未完成時。通常，大多數(shù)基本組件都不能準時可用。假如這些組件不在適當位置您就不能測試您自己的代碼的話，那么您就在朝災(zāi)難走去。您的客戶不會關(guān)心您只有兩個小時來集成遲到了兩周的組件。他們知道的全部就是整套產(chǎn)品被延期了和這是違約的。
　　
　　原則 7. 優(yōu)先編寫測試代碼
　　優(yōu)先編寫測試代碼。這是標準的 XP 方法，但卻總有一種忽視它的誘惑。
　　
　　每次我屈服于這種誘惑時，我都感到后悔。假設(shè)您正努力生產(chǎn)正確的代碼，那么您好象能從推遲編寫測試代碼中節(jié)省的時間其實只是一個幻想。
　　
　　注重：這不是說您應(yīng)該一次性編寫全部測試代碼后，再一次性全部實現(xiàn)。編寫一些測試代碼，實現(xiàn)它們，再編寫一些測試代碼，再實現(xiàn)它們等等是個更好的辦法。設(shè)計以這種方式得以進展；在實現(xiàn)階段捕捉錯誤并在下一組測試中改正它。以這種方式編寫測試也更少會使人畏縮。
　　
　　代碼比您需要的還多？
　　只需一點點努力，就可能輕易地對任何程序進行徹底的測試。當然，不可避免存在這些原則不適用的情況；于是，看起來似乎不可能對功能進行測試。
　　
　　當出現(xiàn)這些情況時，我盡力退一步地看這個問題，“我怎樣才可能測試這種代碼？”相反地，我問自己，“我怎樣才能以可測試方式編寫這些代碼呢？”這種想法上的改變的結(jié)果經(jīng)常是增加了大量僅僅服務(wù)于簡化測試的功能。
　　
　　什么？別擔(dān)心；出現(xiàn)這種情況完全正常。
　　
　　就象很多現(xiàn)有的設(shè)計模式，它們只是為了增加程序的可擴展性就往程序中添加很多類（例如 visitor、decorator 等等），開發(fā)簡化測試的新模式是可以接受的。實際上，面向?qū)ο笳Z言的很多特征都是為了簡化擴展而包含進去的；為什么語言的未來版本（或全新的語言）不應(yīng)包含簡化測試的特征。
　　
　　對 Java 語言來說，這已經(jīng)開始。人們計劃在未來版本中包含很多更強大的類型系統(tǒng)、斷言（assertion）等等。就象面向?qū)ο蟮恼Z言已經(jīng)增加了我們重用和擴展現(xiàn)有代碼的程度，將來，面向測試的設(shè)計和特征將幫助我們增強新老代碼的健壯性。
　　
　　參考資料
　　
　　參加本文的討論論壇。
　　
　　
　　DePaul 大學(xué)的軟件工程系在檢測 Java 空指針異常的自動化法則方面做了一些工作。
　　
　　
　　JUnit 主頁提供討論程序測試方法的很多有趣文章的鏈接，并提供 JUnit 的最新版本。
　　
　　
　　假如您正用 VisualAge for Java 開發(fā)代碼，請看看這篇文章 VisualAge for Java 3.5 中的調(diào)試和單元測試。
　　
　　
　　查閱 iContract ，一個方便您往 Java 代碼中添加斷言的工具。
　　
　　
　　Roy Miller 和 Chris Collins 提供的文章“XP distilled”（developerWorks，2001 年 3 月），說明了極端編程方法如何為您的 Java 工程帶來更大的成功。
　　
　　
　　查閱 ExtremeProgramming.org 上的官方的 XP 編程規(guī)則。
　　
　　
　　想了解如何測試視圖的一些觀點，看看 Eric Allen 關(guān)于 Liar View 錯誤模式的文章（developerWorks，2001 年 4 月）。
　　
　　
　　想更多了解測試視圖的觀點，Jeffries、Anderson 和 Hendrickson 的 Extreme Programming Installed（Addison-Wesley，2001 年）會很有用。
　　
　　
　　想了解為什么使用更高級別的抽象是更有益的（即使它只是在逐步走向前臺），請參閱 Eric Allen 關(guān)于 Impostor Type 錯誤模式的文章（developerWorks，2001 年 7 月）。
　　
　　
　　在 developerWorks Java 技術(shù)專區(qū)上查找更多的 Java 參考資料。
　　
　　
　　關(guān)于作者
　　Eric Allen 從 Cornell 大學(xué)獲得計算機科學(xué)及數(shù)學(xué)的學(xué)士學(xué)位，并且是 Rice 大學(xué) Java 編程語言小組的博士候選人。在回 Rice 完成學(xué)位前，Eric 是 Cycorp，Inc. 的 Java 開發(fā)者帶頭人。他還在 Javaworld 主持“Java 初學(xué)者”討論論壇。他的研究包括在源程序和字節(jié)碼級別上 Java 語言的語義模型和靜態(tài)分析工具開發(fā)。Eric 還幫助開發(fā) Rice 的 NextGen 編程語言編譯器，NextGen 是一個支持泛運行時類型的 Java 擴展。可通過 eallen@cs.rice.edu 與 Eric 聯(lián)系。

上一篇：加密網(wǎng)頁破解大法

下一篇：一個javaBeans的關(guān)于RTTI的問題