合約測試

使用 測試替身 最常見的案例之一是與外部服務進行通訊時。通常此類服務由不同的團隊維護，可能會受到速度慢且不可靠的網路影響，而且本身可能也不可靠。這就是測試替身很方便的原因，它可以防止你自己的測試變得緩慢且不可靠。但是，針對替身進行測試時，總會產生一個問題，即替身是否確實準確代表外部服務，以及如果外部服務變更其合約會發生什麼事？

處理此問題的一個好方法是繼續針對替身執行自己的測試，但除此之外，還要定期執行一組獨立的合約測試。這些測試會檢查針對測試替身的呼叫是否會傳回與呼叫外部服務相同的結果。任何一個合約測試失敗都表示你需要更新測試替身，而且可能需要更新程式碼，以考量服務合約變更。

這些測試不需要作為常規部署管線的一部分來執行。你的常規管線會根據程式碼變更的節奏為基礎，但這些測試需要根據外部服務變更的節奏為基礎。通常一天執行一次就綽綽有餘了。

合約測試失敗不一定要像一般測試失敗那樣中斷建置。但是，它應該會觸發一項工作，讓所有事情再次一致。這可能包括更新測試和程式碼，讓它們與外部服務重新一致。同樣地，它很可能會觸發與外部服務的維護人員進行對話，以討論變更，並提醒他們變更對其他應用程式的影響。

如果此服務用於生產應用程式的部分，則與外部服務供應商的此通訊就更加重要。在這些情況下，合約變更可能會中斷生產應用程式，觸發緊急修復和與供應商團隊進行緊急對話。

若要減少合約意外中斷的機會，採用 消費者驅動合約 方法會很有用。你可以讓供應商團隊取得合約測試的副本，以便他們在建置流程中執行這些測試，藉此促進這項方法。

在測試此類外部服務時，通常最好對外部服務的測試執行個體執行測試。偶爾你別無選擇，只能對生產執行個體執行測試，在這種情況下，你需要與供應商溝通，讓他們知道發生了什麼事，並特別注意測試執行的內容。

合約測試會檢查外部服務呼叫的合約，但不一定會檢查確切的資料。由於資料格式比實際資料更重要，因此存根程式碼通常會在特定日期擷取回應的快照。在這種情況下，合約測試需要檢查格式是否相同，即使實際資料已變更。

建立這些測試替身的最佳方法之一是使用 SelfInitializingFake。