如何為契約提供動態值？

與 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"
}

想象一下，透過改變系統時鐘或提供資料提供者的 Stub 實現來設定 time 欄位的正確值（假設此內容由資料庫生成）是多麼痛苦。id 欄位也是如此。你可以建立一個 Stub 的 UUID 生成器實現，但這沒有多大意義。

因此，作為消費者，您希望傳送一個匹配任意時間或任意 UUID 形式的請求。這樣，您的系統就可以像往常一樣工作，無需您去 Stubbing 任何東西即可生成資料。假設，對於上述 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 的具體值。假設您在生產者端生成這些值。同樣，您必須進行大量的 Stubbing 以確保始終返回相同的值。這就是為什麼從生產者的角度來看，您可能希望得到以下響應

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

那麼，如何為消費者提供匹配器，同時為生產者提供具體值（在其他時候則相反）呢？Spring Cloud Contract 允許您提供一個動態值。這意味著它對於通訊的雙方可以不同。

您可以在契約 DSL一節中瞭解更多資訊。

閱讀Groovy 關於 JSON 的文件，瞭解如何正確構造請求和響應體。