基于測試概念進行代碼設計的七條基本原則

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

        徹底測試代碼的重要性是顯然的?；ㄔ诰帉憸y試和測試代碼上的時間和精力給您帶來的回報是維護成本的大幅降低。

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

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

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

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

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

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

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

        當然，視圖中也可能存在錯誤。在理想情況下，對程序的測試將同時檢查模型和視圖。

原則2：使用類型進行錯誤檢查

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

        類型能在程序運行之前自動捕捉程序中的錯誤。沒有靜態類型檢查的話，類型錯誤將作為破壞者逗留在您的程序中，直到恰當的執行路徑碰巧把它揭露出來為止。

        最大限度地發揮使用類型的長處是棘手的。通常，一組數據結構可以在一個抽象級別上一起使用，或者被分出，成為一個單一的、更高抽象級別的一個新的相關數據類型。

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

        在每一抽象級別上，達到與更高級別抽象一致的功能是可能的，但那實質上僅僅是耗費更多精力，冒更多的錯誤風險。

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

        通常，高級別抽象帶來的健壯性和簡單性的價值很少被其它考慮事項超過。

原則3：使用調節器避免“故障線路”（fault line）

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

        找出程序的故障線路，然后用具有轉發功能的調節器快速訪問聚合組件。

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

        不用隔離測試，而是擁有您在它上面調用您想測試的各種方法的單個調節器對象通常是有幫助的。這個對象然后能把這些方法調用轉發到適當的地方。

      

原文轉自：http://www.anti-gravitydesign.com