此版本仍在开发中，尚未被视为稳定版本。对于最新的稳定版本，请使用 spring-cloud-contract 4.1.5！spring-doc.cn

如何为合约提供动态值？

与 stub 相关的最大挑战之一是它们的可重用性。只有它们能够得到广泛使用，它们才能达到其目的。请求和响应元素的硬编码值（例如日期和 ID）通常会使这变得困难。请考虑以下 JSON 请求：spring-doc.cn

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

现在考虑以下 JSON 响应：spring-doc.cn

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

想象一下设置字段的适当值所需的痛苦（假设此内容由 database）通过更改系统中的 clock 或通过提供数据提供程序的存根实现。同样是相关的到现场。您可以创建 UUID 生成器的存根实现，但这样做几乎没有意义。timeidspring-doc.cn

因此，作为使用者，您希望发送与任何形式的时间或任何 UUID 匹配的请求。这样，您的系统像往常一样工作，无需您存根任何内容即可生成数据。假设，在上述情况下 JSON，最重要的部分是字段。您可以专注于此并为其他字段提供匹配。换句话说，您希望存根的工作方式如下：bodyspring-doc.cn

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

就响应而言，作为消费者，您需要一个可以操作的具体价值。因此，以下 JSON 有效：spring-doc.cn

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

在前面的部分中，我们从 Contract 生成了测试。因此，从生产商的角度来看，情况看起来大不相同。我们解析提供的 Contract，并在测试中向你的 endpoints 发送一个真实的请求。因此，对于请求的 producer 的情况，我们不能进行任何形式的匹配。我们需要具体的值，其中 producer 的后端可以工作。因此，以下 JSON 将有效：spring-doc.cn

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

另一方面，从合同有效性的角度来看，回应不一定必须包含或的具体值。假设您在生产者端生成这些 API。同样，您必须进行大量 stub 以确保始终返回相同的值。这就是为什么从制片人的角度来看，您可能需要以下响应：timeidspring-doc.cn

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

那么，您如何为消费者提供匹配器，为生产者提供具体值（在其他时间则相反）？ Spring Cloud Contract 允许您提供动态值。这意味着两者可能不同沟通的双方。spring-doc.cn

您可以在 Contract DSL 部分阅读更多相关信息。spring-doc.cn

阅读与 JSON 相关的 Groovy 文档以了解如何正确构建请求和响应正文。