如何為合約提供動態值？

與 Stub 相關的最大挑戰之一是它們的可重複使用性。只有當它們可以被廣泛使用時，它們才能達到其目的。請求和回應元素的硬編碼值（例如日期和 ID）通常使這變得困難。請考慮以下 JSON 請求

{
    "time" : "2016-10-10 20:10:15",
    "id" : "9febab1c-6f36-4a0b-88d6-3b6a6d81cd4a",
    "body" : "foo"
}

現在考慮以下 JSON 回應

{
    "time" : "2016-10-10 21:10:15",
    "id" : "c4231e1f-3ca9-48d3-b7e7-567d55f0d051",
    "body" : "bar"
}

想像一下，為了設定 time 欄位的適當值（假設此內容是由資料庫產生），需要透過變更系統中的時鐘或透過提供資料提供者的 Stub 實作來完成這項操作的痛苦。id 欄位也是如此。您可以建立 UUID 產生器的 Stub 實作，但這樣做沒有什麼意義。

因此，作為消費者，您希望傳送符合任何形式時間或任何 UUID 的請求。這樣，您的系統就可以像往常一樣運作，產生資料而無需您 Stub 任何東西。假設在上述 JSON 的情況下，最重要的部分是 body 欄位。您可以專注於該欄位，並為其他欄位提供比對。換句話說，您希望 Stub 像這樣運作

{
    "time" : "SOMETHING THAT MATCHES TIME",
    "id" : "SOMETHING THAT MATCHES UUID",
    "body" : "foo"
}

就回應而言，作為消費者，您需要一個可以運作的具體值。因此，以下 JSON 是有效的

{
    "time" : "2016-10-10 21:10:15",
    "id" : "c4231e1f-3ca9-48d3-b7e7-567d55f0d051",
    "body" : "bar"
}

在先前的章節中，我們從合約產生了測試。因此，從生產者的角度來看，情況大不相同。我們剖析提供的合約，並且在測試中，我們想要將真實請求傳送到您的端點。因此，對於生產者的請求案例，我們不能有任何形式的比對。我們需要生產者的後端可以運作的具體值。因此，以下 JSON 將是有效的

{
    "time" : "2016-10-10 20:10:15",
    "id" : "9febab1c-6f36-4a0b-88d6-3b6a6d81cd4a",
    "body" : "foo"
}

另一方面，從合約有效性的角度來看，回應不一定必須包含 time 或 id 的具體值。假設您在生產者端產生這些值。同樣，您必須進行大量 Stub，以確保您始終傳回相同的值。這就是為什麼從生產者的角度來看，您可能想要以下回應

{
    "time" : "SOMETHING THAT MATCHES TIME",
    "id" : "SOMETHING THAT MATCHES UUID",
    "body" : "bar"
}

那麼，您如何為消費者提供比對器，並為生產者提供具體值（以及在其他時間的相反情況）？Spring Cloud Contract 允許您提供動態值。這表示對於通訊的雙方而言，它可以有所不同。

您可以在合約 DSL 章節中閱讀更多相關資訊。

請閱讀與 JSON 相關的 Groovy 文件，以了解如何正確建構請求和回應主體。