可測性模式（下）

Sep. 24 14:00~15:15

 

昨天介紹的Dependency Injection和Dependency Lookup是鄉民們比較熟悉的pattern，今天要介紹Humble Object與Test Hook，前者鄉民們可能比較少用到，實作上也比較麻煩，但可以解決許多SUT與DOC緊密耦合導致測試困難的情況。

 

Humble Object

許多程式開發會使用框架（framework）或是以外掛程式（plug-in）的形式執行在宿主（host）之上，小到撰寫thread程式，大到撰寫GUI程式、JE22元件或Eclipse外掛。在這種情況下，SUT與DOC緊密耦合，而且DOC非常巨大或特殊，難以用Dependency Injection和Dependency Lookup來解決不易測試的問題。怎麼辦？

Humble Object講穿了也很簡單，就是把原本的SUT拆開變成兩個部分，一個部分是將SUT自身的程式邏輯抽離出來放在Testable Component身上以便單獨測試。另一部分是將Testable Component需要呼叫到DOC的程式或是DOC需要回呼（callback）Testable Component的部分由Humble Object代勞。換句話說原本的SUT變成了：

• Testable Component：可以被單獨測試，在測試情況下可以用Test Double來取代Humble Object。
• Humble Object：隔離Testable Component與DOC。

這個pattern多年前Teddy還在唸書的時候有一陣子在研究MVC pattern，當初就有人提出來用以解決UI測試的問題。簡單的說，在View與Model之間增加一個Humble Object隔離Model與View，如此便可單獨測試Model。因為Humble Object基本上沒有複雜的邏輯，類似一個Adapter，轉接真正UI與Model之間的呼叫，所以雖然Humble Object與View有緊密的相依性，但因為邏輯很簡單，沒有自動化測試也還可以接受。

***

Humble Object在Testable Component與DOC之間增加了一層用以隔離待測程式與DOC的相依性，理論上這個pattern可以解決很多測試困難的問題。但是，如果DOC真的異常巨大（例如J2EE或Eclipse），而且SUT使用到很多DOC的服務，則光是撰寫Humble Object成功隔離SUT與DOC就是一件苦差事，而且還要修改原本的設計以便分離Humble Object與Testable Component。所以，很多人懶得套用Humble Object，會直接利用Test Double，看看有沒有人實作Fake的DOC或是透過Mock Object Library直接用「貍貓換太子」的手段在不修改SUT的情況下撰寫測試。

 

Test Hook

這個pattern相信很多人都用過，最簡單的形式就是在程式中設一個變數，判斷現在是否處於測試模式。如果是，就呼叫假的DOC，如果不是，就呼叫真的DOC。

if(TESTING) {

…..

}

else {

…..

}

 

這種作法雖然簡單，有時候也的確有用，但程式中有寫死的邏輯總是一種壞味道，非不得已還是少用為妙。

***

友藏內心獨白：可測性和設計有關，所以這些pattern才被歸類為design for testability。