Consumer-Driven Contracts: Stubs Per Consumer

在某些情况下，同一个端点的两个消费者希望得到两个不同的响应。

There are cases in which two consumers of the same endpoint want to have two different responses.

此方法还使你可以立即知道哪个使用者使用了api的哪一部分。你可以删除api产生的部分响应，并查看你的自动生成测试中的哪一个失败。如果没有任何失败，则可以安全删除该部分响应，因为没有人使用它。

This approach also lets you immediately know which consumer uses which part of your API. You can remove part of a response that your API produces and see which of your autogenerated tests fails. If none fails, you can safely delete that part of the response, because nobody uses it.

请考虑以下针对名为 producer 的生产者定义的契约示例，它有两个消费者（foo-consumer 和 bar-consumer）：

Consider the following example of a contract defined for the producer called producer, which has two consumers (foo-consumer and bar-consumer):

Consumer foo-service

request {
   url '/foo'
   method GET()
}
response {
    status OK()
    body(
       foo: "foo"
    }
}

Consumer bar-service

request {
   url '/bar'
   method GET()
}
response {
    status OK()
    body(
       bar: "bar"
    }
}

您无法为同一个请求生成两个不同的响应。这就是您可以正确打包契约然后从 stubsPerConsumer 特性中获益的原因。

You cannot produce two different responses for the same request. That is why you can properly package the contracts and then profit from the stubsPerConsumer feature.

在生产者端，消费者可以有一个仅包含与它们相关的契约的文件夹。通过将 stubrunner.stubs-per-consumer 标志设置为 true，我们不再注册所有存根，而仅注册与消费者应用程序名称对应的存根。换句话说，我们扫描每个存根的路径，如果该路径中包含一个子文件夹的名称是消费者，则仅注册该存根。

On the producer side, the consumers can have a folder that contains contracts related only to them. By setting the stubrunner.stubs-per-consumer flag to true, we no longer register all stubs but only those that correspond to the consumer application’s name. In other words, we scan the path of every stub and, if it contains a subfolder with name of the consumer in the path, only then is it registered.

在 foo 生产者端，契约如下所示：

On the foo producer side the contracts would look like this

.
└── contracts
    ├── bar-consumer
    │   ├── bookReturnedForBar.groovy
    │   └── shouldCallBar.groovy
    └── foo-consumer
        ├── bookReturnedForFoo.groovy
        └── shouldCallFoo.groovy

bar-consumer 消费者可以将 spring.application.name 或 stubrunner.consumer-name 设置为 bar-consumer。或者，您可以按如下方式设置测试：

The bar-consumer consumer can either set the spring.application.name or the stubrunner.consumer-name to bar-consumer Alternatively, you can set the test as follows:

Unresolved directive in stub-runner-stubs-per-consumer.adoc - include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/spring/cloud/StubRunnerStubsPerConsumerSpec.groovy[]
...
}

然后，仅允许引用在名称中包含 bar-consumer 的路径下注册的存根（即来自 src/test/resources/contracts/bar-consumer/some/contracts/… 文件夹的存根）。

Then only the stubs registered under a path that contains bar-consumer in its name (that is, those from the src/test/resources/contracts/bar-consumer/some/contracts/… folder) are allowed to be referenced.

您也可以显式设置使用者名称，如下所示：

You can also set the consumer name explicitly, as follows:

Unresolved directive in stub-runner-stubs-per-consumer.adoc - include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/spring/cloud/StubRunnerStubsPerConsumerWithConsumerNameSpec.groovy[]
...
}

然后，仅允许引用名称中包含 foo-consumer 的路径下注册的 stub（即那些位于 src/test/resources/contracts/foo-consumer/some/contracts/… 文件夹中的 stub）。

Then only the stubs registered under a path that contains the foo-consumer in its name (that is, those from the src/test/resources/contracts/foo-consumer/some/contracts/… folder) are allowed to be referenced.

欲了解此更改背后的原因的更多信息，请参阅 issue 224。

For more information about the reasons behind this change, see issue 224.