l

2014年9月26日 星期五

Test Double(2):五種替身簡介

Sep. 22 17:09~19:42

螢幕截圖 2014-09-22 17.12.08

 

依據《xUnit Test Patterns》的解釋,五種Test Double的含意如上圖所示。不過讀完之後還是有點小疑惑,如果再配合MSDN Magazine上面的這張圖,就更容易理解了。

螢幕截圖 2014-09-22 17.19.44

 

從Test Double與本尊之間的功能相似度來區分,Dummy Object根本沒有實作,是「假到非常假」的替身。Stub有實作,但是其實作方式通常採用寫死某個特定回傳值的方式。Spy和Stub類似也都有實作,但是Stub用來應付「state verification」(狀態驗證),而Spy則是用來應付「behavior verification」」(行為驗證)。Spy會記錄SUT與DOC之間的行為互動,例如在上一集所提到的Observer設計模式,如果要測試Subject與Observer之間的互動,就可以用Spy技術來替代Observer。Fake則是與本尊行為非常接近的替身,差別在於Fake採用比較簡單的方式來實作本尊的功能。例如,本尊是SQL Server,而測試的時候為了速度考量,使用HSQL這個in-memory的資料庫來做為替身。

最後一種Test Double是Mock Object,從上圖來看,Mock技術可以做到Dummy、Stub、Spy的功能,但比較無法做到Fake。簡單的說,Mock技術可以藉由Mock Object Library自動產生Dummy、Stub或Spy這三種Test Double,而不需要開發人員自己動手寫。

***

接下來的幾集將以一個應用Command模式的監控程式為例子,說明應用這五種Test Double的測試技巧。

***

友藏內心獨白:Mock是一種自動產生Test Double的技術。

2 則留言:

  1. 既然Fake採用比較簡單的方式來實作, 那是否有需要對Fake作Unit test?

    回覆刪除
    回覆
    1. 印象中我沒有對Fake做過單元測試,Fake 如果是拿現成輕量級的軟體來取代原本DOC實作,如此便不需測試Fake。如果是自己實作的Fake,一般來說不會太過複雜,如果Fake有問題測試SUT便會失敗,這時候就知道要修改Fake。

      刪除