l

2014年10月10日 星期五

可測性模式(下)

Sep. 24 14:00~15:15

image

 

昨天介紹的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。

沒有留言:

張貼留言