如何為契約提供動態值？

與存根相關最大的挑戰之一是其可重用性。只有當它們被廣泛使用時，它們才能發揮其作用。請求和響應元素的硬編碼值（例如日期和 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 欄位的正確值（假設此內容由資料庫生成）所需的痛苦。id 欄位也與此相關。你可以建立 UUID 生成器的存根實現，但這幾乎沒有意義。

因此，作為消費者，你希望傳送一個匹配任何時間或任何 UUID 形式的請求。這樣，你的系統就可以像往常一樣工作，生成資料，而無需你存根任何東西。假設，在上述 JSON 的情況下，最重要的部分是 body 欄位。你可以專注於此併為其他欄位提供匹配。換句話說，你希望存根能以下列方式工作

{
    "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 的具體值。假設你在生產者端生成這些。同樣，你必須進行大量的存根操作以確保你始終返回相同的值。這就是為什麼，從生產者的角度來看，你可能希望得到以下響應

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

那麼，你如何為消費者提供匹配器，併為生產者提供具體值（有時則相反）？Spring Cloud Contract 允許你提供動態值。這意味著它在通訊雙方可能不同。

你可以在契約 DSL 部分閱讀更多相關資訊。

閱讀 Groovy JSON 相關文件以瞭解如何正確構建請求和響應體。