如何为契约提供动态值？

与 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 的文档，了解如何正确构造请求和响应体。