對付時好時壞的測試案例(4)：Remote Services

Nov. 27 17:42~18:37

Remote Services

第三種造成測試案例時好時壞的原因叫做Remote Services（遠端服務），還是用看圖說明比較快。

 

假設你的應用程式需取得「政府實價登錄網站」中的資料，那麼這個「政府實價登錄網站」對你的應用程式而言就是一個遠端服務。最近有看新聞的鄉民們應該都知道，「政府實價登錄網站」的行為是會改變的，像是價錢、地段等資料，從原本的純文字被改成圖片。除此之外，「政府實價登錄網站」還可能因為同時上線使用者太多，而導致有些人連不上去，無法使用該系統。在這種情況之下，如果鄉民的測試案例會直接呼叫「政府實價登錄網站」的服務內容，這樣的測試案例就很容易因為「政府實價登錄網站」這個遠端服務的行為改變，而造成測試案例時好時壞的現象。

 

怎麼辦

解決遠端服務所造成測試案例不穩定的問題，最常用的方法就是套用所謂的Test Double（測試替身）這個測試模式。這個概念也很簡單，既然遠端服務的行為無法控制，那麼就自己幫這個遠端服務開發一個假的「測試替身」，用來代替原本真正的遠端服務。這個為了測試用途所做出來的替身，它的行為可以是最簡單的只接受對方的呼叫並列出對方傳過來的參數（Dummy）、很簡單的只要應付特定規劃好的測試路徑所期待的結果（類似mock object），或是複雜一點，實作與實際遠端服務類似功能（stub）等等。測試替身通常和你的待測程式（也就是你的應用程式）都放在相同的環境當中，而且都受你所控制，所以可以辦免發生測試案例時好時壞的問題。

 

可是你沒有測試到真實的遠端服務啊

看到這邊鄉民們可能會想，使用測試替身這一招雖然可以增加測試案例的穩定性，但是這樣一來，就沒有測試到原本真正的遠端服務。舉「政府實價登錄網站」的例子，如果使用測試替身，第一版「政府實價登錄網站」的價錢、地段等資料是純文字，所以第一版的測試替身也是會回傳純文字。但是有一天「政府實價登錄網站」的價錢、地段等資料突然無預警的改成圖片，但是你的測試替身並不知道這樣的改變，所以測試案例還是通過。換句話說，這個bug（問題或是現象）並沒有被測試案例給找出來啊。

基於上述的原因，因此有很多人堅持當應用程式有使用到遠端服務的時候，一定要真的去呼叫實際的遠端服務，不可以使用測試替身。哇，這下怎麼辦，如果不使用測試替身，那麼這樣的測試案例又可能會變成時好時壞的狀態。

這個問題的癥結在於，鄉民們無法知道「政府實價登錄網站」這個遠端服務和自己實作的測試替身，兩者的行為是否保持一致。對此，Martin Fowler建議大家要撰寫另外一種叫做「Integration Contract Test」（整合合約測試）的測試案例。

 

如下圖所示，Integration Contract Test先呼叫遠端服務，再呼叫測試替身，最後比較這兩者的行為是否一致（例如，傳回資料是否相同）。如果Integration Contract Test失敗，就表示遠端服務的行為已經更改了，因此你的應用程式以及測試替身也要跟著修正。

***

友藏內心獨白：使用測試替身與Integration Contract Test，也是一種separation of concern的做法。