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

songlai

當(dāng)設(shè)計大型程序的時候，您必須時刻留心不同設(shè)計選項(xiàng)對諸如性能和可擴(kuò)展性這樣的特征的影響。隨著軟件產(chǎn)品的日漸復(fù)雜及其無所不在的部署，軟件的“可測試性”也成了更重要的考慮事項(xiàng)。

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

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

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

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

　　原則 1. 到 GUI 視圖的外面去

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

　　對 GUI 測試者來說，通過方法調(diào)用測試功能比間接地測試功能容易的多。

　　另一個好處是它使修改程序功能而不影響視圖變的更容易。

　　當(dāng)然，視圖中也可能存在錯誤。在理想情況下，對程序的測試將同時檢查模型和視圖。（想更多了解測試視圖，請參閱我關(guān)于 Liar View 錯誤模式的文章或 Jeffries 等人的 Extreme Programming Installed。這兩個鏈接都在參考資料部分。）

　　原則 2. 使用類型進(jìn)行錯誤檢查

　　類型是您的朋友 — 盡可能多地用類型系統(tǒng)自動檢查錯誤。

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

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

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

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

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

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

　　原則 3. 使用調(diào)節(jié)器避免“故障線路”（fault line）

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

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

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

　　不用隔離測試，而是擁有您在它上面調(diào)用您想測試的各種方法的單個調(diào)節(jié)器對象通常是有幫助的。這個對象然后能把這些方法調(diào)用轉(zhuǎn)發(fā)到適當(dāng)?shù)牡胤健?/font>

　　沿著相同線路，設(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í)驗(yàn)室試驗(yàn)相似。它們都想證明特定假設(shè)有效。如果特定檢查動作改變了該領(lǐng)域的狀態(tài)，那么要這樣做會變得困難的多。

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

　　原則 6. 用接口說明外部程序組件

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

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

　　原則 7. 優(yōu)先編寫測試代碼

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

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

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

　　代碼比您需要的還多？

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

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

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

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

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

來源于北京教育招生網(wǎng)