沿著相同線路，設計和自己的測試代碼串聯在一起的程序組件接口是有益的。這將使您把注意力集中在使這些接口盡可能簡單上。
原則 4. 方法：小型簽名和缺省參數
使用小型方法說明和重載帶缺省方法參數的方法將使您在測試中調用這些方法變的愉快的多。否則，在測試這些方法時您將不得不構造額外參數。如果參數很大，那么將很快導致代碼膨脹。更糟的是，它會誘使您編寫比在其它情況下更少的測試。
原則 5. 訪問器不應修改內存狀態
請在您的測試中使用不修改內存狀態的訪問器來檢查對象狀態。
在某些方面，測試和實驗室試驗相似。它們都想證明特定假設有效。如果特定檢查動作改變了該領域的狀態，那么要這樣做會變得困難的多。
與量子力學領域不同，計算機進程的狀態可以不修改就被檢查。使用這種原則對您有好處。
原則 6. 用接口說明外部程序組件
用接口說明外部程序組件使得我們可以容易地在測試案例中模擬這些組件。
這條原則能節省大量時間，特別是當外部組件的實現還未完成時。通常，大多數基本組件都不能準時可用。如果這些組件不在適當位置您就不能測試您自己的代碼的話，那么您就在朝災難走去。您的客戶不會關心您只有兩個小時來集成遲到了兩周的組件。他們知道的全部就是整套產品被延期了和這是違約的。
原則 7. 優先編寫測試代碼
優先編寫測試代碼。這是標準的 XP 方法，但卻總有一種忽視它的誘惑。
每次我屈服于這種誘惑時，我都感到后悔。假設您正努力生產正確的代碼，那么您 好象能從推遲編寫測試代碼中節省的時間其實只是一個幻想。
注意：這不是說您應該一次性編寫全部測試代碼后，再一次性全部實現。編寫一些測試代碼，實現它們，再編寫一些測試代碼，再實現它們等等是個更好的辦法。設計以這種方式得以進展;在實現階段捕捉錯誤并在下一組測試中改正它。以這種方式編寫測試也更少會使人畏縮。
代碼比您需要的還多?
只需一點點努力，就可能容易地對任何程序進行徹底的測試。當然，不可避免存在這些原則不適用的情況;于是，看起來好像不可能對功能進行測試。
當出現這些情況時，我盡力退一步地看這個問題，“我怎樣才可能測試這種代碼?”相反地，我問自己，“我怎樣才能以可測試方式編寫這些代碼呢?”這種想法上的改變的結果經常是增加了大量 僅僅服務于簡化測試的功能。
什么?別擔心;出現這種情況完全正常。
就象很多現有的設計模式，它們只是為了增加程序的可擴展性就往程序中添加很多類(例如 visitor、decorator 等等)，開發簡化測試的新模式是可以接受的。實際上，面向對象語言的很多特征都是為了簡化擴展而包含進去的;為什么語言的未來版本(或全新的語言)不應包含簡化測試的特征。
對 Java 語言來說，這已經開始。人們計劃在未來版本中包含很多更強大的類型系統、斷言(assertion)等等。就象面向對象的語言已經增加了我們重用和擴展現有代碼的程度，將來，面向測試的設計和特征將幫助我們增強新老代碼的健壯性。
文章來源于領測軟件測試網 http://www.kjueaiud.com/