心存測試概念進(jìn)行代碼設(shè)計(jì)時(shí)的七條基本原則

2019-11-18 15:17:47

字體：大中小

供稿：網(wǎng)友

　　心存測試概念進(jìn)行代碼設(shè)計(jì)時(shí)的七條基本原則
Eric E. Allen (eallen@cs.rice.edu)
博士研究生候選人，Rice 大學(xué)

在診斷 java 代碼的這一部分中，Eric Allen 暫停了對具體錯(cuò)誤模式的討論，轉(zhuǎn)而選擇討論關(guān)于設(shè)計(jì)易于、甚至我們樂于測試的軟件的問題。他概述了七條設(shè)計(jì)原則，這些原則能大幅提高您編寫測試代碼的效率并因此提高結(jié)果代碼庫的健壯性。請?jiān)谟懻撜搲c作者和其它讀者共享您關(guān)于本文的心得。
謹(jǐn)以本文獻(xiàn)給周二攻擊的受害者，向?yàn)?zāi)難挑戰(zhàn)的英雄們和美國人民的鋼鐵意志。
當(dāng)設(shè)計(jì)大型程序的時(shí)候，您必須時(shí)刻留心不同設(shè)計(jì)選項(xiàng)對諸如性能和可擴(kuò)展性這樣的特征的影響。隨著軟件產(chǎn)品的日漸復(fù)雜及其無所不在的部署，軟件的“可測試性”也成了更重要的考慮事項(xiàng)。

徹底測試代碼的重要性是顯然的。花在編寫測試和測試代碼上的時(shí)間和精力給您帶來的回報(bào)是維護(hù)成本的大幅降低。

然而，除非您很小心，否則您花在測試代碼上的精力可能會首先達(dá)到花在編寫代碼上的精力的幾倍！我曾看到程序員們齊心協(xié)力地對他們的全部代碼進(jìn)行單元測試，結(jié)果花在上面的時(shí)間使大多數(shù)人都以沮喪而告終。

幸運(yùn)的是，沒有必要這樣。在您設(shè)計(jì)軟件的時(shí)候應(yīng)用一些基本原則，編寫易于測試、甚至使測試成為樂趣的代碼是可能的。

跟其它編碼原則一樣，這些原則也不是不容置疑或不可改變的教條。有時(shí)候打破這些規(guī)則也是必要的。因此，理解每條原則背后的動機(jī)和判定何時(shí)這些動機(jī)不適用（或應(yīng)讓位給更關(guān)心的問題）的能力是很重要的。

原則 1. 到 GUI 視圖的外面去
盡可能把代碼移到 GUI 視圖的外面。然后各種 GUI 動作就能成了模型上的簡單方法調(diào)用。為什么您需要這樣做呢？

對 GUI 測試者來說，通過方法調(diào)用測試功能比間接地測試功能輕易的多。
另一個(gè)好處是它使修改程序功能而不影響視圖變的更輕易。
當(dāng)然，視圖中也可能存在錯(cuò)誤。在理想情況下，對程序的測試將同時(shí)檢查模型和視圖。（想更多了解測試視圖，請參閱我關(guān)于 Liar View 錯(cuò)誤模式的文章或 Jeffries 等人的 Extreme PRogramming Installed。這兩個(gè)鏈接都在參考資料部分。）

原則 2. 使用類型進(jìn)行錯(cuò)誤檢查
類型是您的朋友 ? 盡可能多地用類型系統(tǒng)自動檢查錯(cuò)誤。

類型能在程序運(yùn)行之前自動捕捉程序中的錯(cuò)誤。沒有靜態(tài)類型檢查的話，類型錯(cuò)誤將作為破壞者逗留在您的程序中，直到恰當(dāng)?shù)膱?zhí)行路徑碰巧把它揭露出來為止。

最大限度地發(fā)揮使用類型的優(yōu)點(diǎn)是棘手的。通常，一組數(shù)據(jù)結(jié)構(gòu)可以在一個(gè)抽象級別上一起使用，或者被分出，成為一個(gè)單一的、更高抽象級別的一個(gè)新的相關(guān)數(shù)據(jù)類型。

事實(shí)上，編程語言自身的歷史可以看成是可以編程的抽象級別的逐漸提高。匯編語言提供了比特到整數(shù)和浮點(diǎn)數(shù)的抽象。接下來是記錄和函數(shù)抽象，然后又是諸如對象、類、線程以及異常這樣的抽象。

在每一抽象級別上，達(dá)到與更高級別抽象一致的功能是可能的，但那實(shí)質(zhì)上僅僅是耗費(fèi)更多精力，冒更多的錯(cuò)誤風(fēng)險(xiǎn)。

在面向?qū)ο笳Z言（其它現(xiàn)代語言也一樣）中，一個(gè)程序員在設(shè)計(jì)抽象上有很大的靈活性。在哪個(gè)抽象級別上設(shè)計(jì)程序就成了基于折衷的決定，比如由抽象級別提供的更多的健壯性和由于不能在更低抽象級別上工作而帶來的表達(dá)性（有時(shí)是性能）的損失。

通常，高級別抽象帶來的健壯性和簡單性的價(jià)值很少被其它考慮事項(xiàng)超過。（要了解對這個(gè)問題的更多討論，請參閱我關(guān)于 Impostor Type 錯(cuò)誤模式的文章，在參考資料部分有它的鏈接。）

原則 3. 使用調(diào)節(jié)器避免“故障線路”（fault line）
我用“故障線路”來指獨(dú)立組件之間的接口，獨(dú)立組件之間和組件與其相應(yīng)子組件之間相比，很少有交互。這種故障線路的一個(gè)典型示例是 GUI 視圖和它的模型之間的接口。其它示例包括在編譯器中處理的不同階段之間的接口或操作系統(tǒng)的內(nèi)核和用戶界面之間的接口。

找出程序的故障線路，然后用具有轉(zhuǎn)發(fā)功能的調(diào)節(jié)器快速訪問聚合組件。

沿著故障線路隔離測試每個(gè)組件通常更輕易。但假如每個(gè)組件暴露的對象有很多，或者組件中您想測試的一些對象只有通過多個(gè)嵌套引用才能訪問，那么測試就會變的很乏味。

不用隔離測試，而是擁有您在它上面調(diào)用您想測試的各種方法的單個(gè)調(diào)節(jié)器對象通常是有幫助的。這個(gè)對象然后能把這些方法調(diào)用轉(zhuǎn)發(fā)到適當(dāng)?shù)牡胤健?br />
沿著相同線路，設(shè)計(jì)和自己的測試代碼串聯(lián)在一起的程序組件接口是有益的。這將使您把注重力集中在使這些接口盡可能簡單上。

原則 4. 方法：小型簽名和缺省參數(shù)
使用小型方法說明和重載帶缺省方法參數(shù)的方法將使您在測試中調(diào)用這些方法變的愉快的多。否則，在測試這些方法時(shí)您將不得不構(gòu)造額外參數(shù)。假如參數(shù)很大，那么將很快導(dǎo)致代碼膨脹。更糟的是，它會誘使您編寫比在其它情況下更少的測試。

原則 5. 訪問器不應(yīng)修改內(nèi)存狀態(tài)
請?jiān)谀臏y試中使用不修改內(nèi)存狀態(tài)的訪問器來檢查對象狀態(tài)。

在某些方面，測試和實(shí)驗(yàn)室試驗(yàn)相似。它們都想證實(shí)特定假設(shè)有效。假如特定檢查動作改變了該領(lǐng)域的狀態(tài)，那么要這樣做會變得困難的多。

與量子力學(xué)領(lǐng)域不同，計(jì)算機(jī)進(jìn)程的狀態(tài)可以不修改就被檢查。使用這種原則對您有好處。

原則 6. 用接口說明外部程序組件
用接口說明外部程序組件使得我們可以輕易地在測試案例中模擬這些組件。

這條原則能節(jié)省大量時(shí)間，非凡是當(dāng)外部組件的實(shí)現(xiàn)還未完成時(shí)。通常，大多數(shù)基本組件都不能準(zhǔn)時(shí)可用。假如這些組件不在適當(dāng)位置您就不能測試您自己的代碼的話，那么您就在朝災(zāi)難走去。您的客戶不會關(guān)心您只有兩個(gè)小時(shí)來集成遲到了兩周的組件。他們知道的全部就是整套產(chǎn)品被延期了和這是違約的。

原則 7. 優(yōu)先編寫測試代碼
優(yōu)先編寫測試代碼。這是標(biāo)準(zhǔn)的 XP 方法，但卻總有一種忽視它的誘惑。

每次我屈服于這種誘惑時(shí)，我都感到后悔。假設(shè)您正努力生產(chǎn)正確的代碼，那么您好象能從推遲編寫測試代碼中節(jié)省的時(shí)間其實(shí)只是一個(gè)幻想。

注重：這不是說您應(yīng)該一次性編寫全部測試代碼后，再一次性全部實(shí)現(xiàn)。編寫一些測試代碼，實(shí)現(xiàn)它們，再編寫一些測試代碼，再實(shí)現(xiàn)它們等等是個(gè)更好的辦法。設(shè)計(jì)以這種方式得以進(jìn)展；在實(shí)現(xiàn)階段捕捉錯(cuò)誤并在下一組測試中改正它。以這種方式編寫測試也更少會使人畏縮。

代碼比您需要的還多？
只需一點(diǎn)點(diǎn)努力，就可能輕易地對任何程序進(jìn)行徹底的測試。當(dāng)然，不可避免存在這些原則不適用的情況；于是，看起來似乎不可能對功能進(jìn)行測試。

當(dāng)出現(xiàn)這些情況時(shí)，我盡力退一步地看這個(gè)問題，“我怎樣才可能測試這種代碼？”相反地，我問自己，“我怎樣才能以可測試方式編寫這些代碼呢？”這種想法上的改變的結(jié)果經(jīng)常是增加了大量僅僅服務(wù)于簡化測試的功能。

什么？別擔(dān)心；出現(xiàn)這種情況完全正常。

就象很多現(xiàn)有的設(shè)計(jì)模式，它們只是為了增加程序的可擴(kuò)展性就往程序中添加很多類（例如 visitor、decorator 等等），開發(fā)簡化測試的新模式是可以接受的。實(shí)際上，面向?qū)ο笳Z言的很多特征都是為了簡化擴(kuò)展而包含進(jìn)去的；為什么語言的未來版本（或全新的語言）不應(yīng)包含簡化測試的特征。

對 Java 語言來說，這已經(jīng)開始。人們計(jì)劃在未來版本中包含很多更強(qiáng)大的類型系統(tǒng)、斷言（assertion）等等。就象面向?qū)ο蟮恼Z言已經(jīng)增加了我們重用和擴(kuò)展現(xiàn)有代碼的程度，將來，面向測試的設(shè)計(jì)和特征將幫助我們增強(qiáng)新老代碼的健壯性。

參考資料

參加本文的討論論壇。

DePaul 大學(xué)的軟件工程系在檢測 Java 空指針異常的自動化法則方面做了一些工作。

JUnit 主頁提供討論程序測試方法的很多有趣文章的鏈接，并提供 JUnit 的最新版本。

假如您正用 VisualAge for Java 開發(fā)代碼，請看看這篇文章 VisualAge for Java 3.5 中的調(diào)試和單元測試。

查閱 iContract ，一個(gè)方便您往 Java 代碼中添加斷言的工具。

Roy Miller 和 Chris Collins 提供的文章“XP distilled”（developerWorks，2001 年 3 月），說明了極端編程方法如何為您的 Java 工程帶來更大的成功。

查閱 ExtremeProgramming.org 上的官方的 XP 編程規(guī)則。

想了解如何測試視圖的一些觀點(diǎn)，看看 Eric Allen 關(guān)于 Liar View 錯(cuò)誤模式的文章（developerWorks，2001 年 4 月）。

想更多了解測試視圖的觀點(diǎn)，Jeffries、Anderson 和 Hendrickson 的 Extreme Programming Installed（Addison-Wesley，2001 年）會很有用。

想了解為什么使用更高級別的抽象是更有益的（即使它只是在逐步走向前臺），請參閱 Eric Allen 關(guān)于 Impostor Type 錯(cuò)誤模式的文章（developerWorks，2001 年 7 月）。

在 developerWorks Java 技術(shù)專區(qū)上查找更多的 Java 參考資料。

關(guān)于作者
Eric Allen 從 Cornell 大學(xué)獲得計(jì)算機(jī)科學(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 是一個(gè)支持泛運(yùn)行時(shí)類型的 Java 擴(kuò)展。可通過 eallen@cs.rice.edu 與 Eric 聯(lián)系。

上一篇：邂逅StringIndexOutOfBoundsException

下一篇：小議如何在Applet 中顯示圖象