需要的介面還沒完成時，可以先約定要傳入什麼、會回傳什麼，再用測試替身測試呼叫這個介面的程式。

測試替身（Test Double）用來在測試中代替程式依賴的物件或服務。它可以回傳指定資料，或記錄呼叫次數與傳入的參數。

透過測試替身開發清單

以逐步替換舊系統的假想案例為例，新客戶清單透過舊系統的讀取介面取得資料。這次只替換唯讀清單，其餘功能仍由舊系統處理。

讀取介面尚未完成時，可以先約定查詢要傳入哪些條件、回傳哪些欄位，以及讀取失敗時如何回應。再沿用依賴注入的做法，讓清單使用外部提供的資料讀取物件。測試時傳入替身，之後再換成呼叫舊系統介面的實作。兩者遵守相同約定，清單就能沿用原本的呼叫方式。

以下假設舊清單的聯絡電話未填寫時，會顯示「未填寫」。約定介面以 null 表示未填寫後，就可以讓替身提供這種資料，先實作並測試這個提示。沒有客戶資料與讀取失敗時，則讓替身分別回傳空清單與錯誤結果，確認畫面顯示不同的提示。

先整合清單程式與測試

清單程式與替身測試可以先整合到主幹，正式入口繼續使用舊清單，替身只供測試使用。其他成員也能從主幹取得清單程式，繼續開發需要使用清單的功能。

讓替身與讀取介面遵守相同約定

假設清單只在收到 null 時顯示「未填寫」，其他值直接顯示，但讀取介面將未填寫的聯絡電話回傳為空字串。接上介面後，畫面就會留白，但使用替身的測試仍會通過。

可以把約定寫成範例，據此撰寫清單與讀取介面的測試。清單測試檢查是否顯示「未填寫」，讀取介面的測試則使用沒有聯絡電話的資料，檢查是否回傳 null。改變查詢條件或回傳內容時，要一起調整讀取介面、清單與相關測試。

接上舊系統的讀取介面

當讀取介面已能提供清單需要的資料，就可以將清單接上它，不必等其他功能全部完成。替身不會連線到舊系統，也不會執行舊系統的權限判斷。這時要從新清單送出查詢，確認舊系統依登入身分回傳可查看的資料。

如果新清單的查詢或顯示有問題，正式入口就繼續使用舊清單。後續開放新清單時，沿用前面系統替換案例的部署與切換安排。

小結

透過測試替身，清單程式可以在讀取介面完成前整合到主幹。清單與讀取介面按照相同約定分開開發，介面完成後再將兩者接起來。

介面約定除了欄位與型別，也需要說明每個欄位代表什麼，以及呼叫後會執行哪些操作。接著回到逐筆通知與每日摘要的需求，說明業務規則如何影響程式設計。

參考資料

• Martin Fowler：Test Double
• Martin Fowler：Contract Test