对具有请求和响应序列的服务使用pact

Question

下面是我的用例：

我的服务是：ServiceA。
它依赖于以下服务：ServicesB和ServiceC。

ServiceA向ServiceB发送一个POST请求，其中包含一些身份验证细节（用户名+密码），ServiceB返回一个具有sessionID的json文档。

POST /authenticate
{
    "username": "_at_api",
    "password": "xxx"
}

答复：

{
    "sessionId": "axy235da7ad5a24abeb3e7fbb85d0ef45f"
}

上面的sessionId用于从ServiceA到ServiceC的所有api调用。

ServiceA请求serviceC使用POST请求启动作业，serviceC返回作业id（字母数字）。

POST /jobs/local/start
Header: Authentication: axy235da7ad5a24abeb3e7fbb85d0ef45f
{
    ...
}

{
    "status": "RUNNING",
    "jobId": "a209016e3fdf4425ea6e5846b8a46564abzt"
}

ServiceA使用上面返回的jobId继续轮询serviceC以确定作业是否完成：

请求：

GET /jobs/status/a209016e3fdf4425ea6e5846b8a46564abzt
Header: Authentication: axy235da7ad5a24abeb3e7fbb85d0ef45f

答复：

{
    "status": "RUNNING"
}

{
    "status": "COMPLETED"
}

我的计划是只使用单元测试和契约测试来实现90%以上的代码覆盖率。这是一个好主意，还是我需要使用虚拟服务器进行单独的测试？我的理解是，Pact是虚拟服务器的超集（例如：mountebank)，虚拟服务器可以做的一切，Pact都可以做。因此我不需要单独的组件测试。而且，合同测试看起来完全取代了端到端测试，所以我也不需要端到端测试。这样对吗？

Answer 1

而且，合同测试看起来完全取代了端到端测试，所以我也不需要端到端测试。这样对吗？

不是。契约测试不是功能测试（参见这篇优秀的文章，标题相同）

契约测试是关于测试两个组件是否能够通信。

null

在这个假设的情况下，我们的邮递员在那些情况下并没有做任何不同的事情--他们只是无法投递。所以，从合同的角度来看，失败的原因是无关紧要的。可以对合同进行测试，而不需要列举所有可能失败的原因，工人可以尝试交付post（邮递），他们可以是成功的，也可以是不成功的。

更详细的例子见上面链接的文章，但引用它的结尾：

合同应包括：

null

可以使用Pact这样的工具来替换端到端测试。然而，尽管契约测试与端到端测试所需的特性有很多相似之处，但契约测试（尤其是Pact）并不是为端到端测试而设计的。

如果您是通过扩展现有的消费者测试来进行端到端测试（例如，将所有可能导致失败的原因添加到后期工作人员的测试中），那么合同意味着什么就不再清楚了。合同现在描述了通信是如何与行为一起工作的。

当你开始添加更多的消费者（比如，一个包裹快递员）时，这会引起问题--你是复制所有消费者中的所有失败案例，还是仅仅保留在最初的消费者测试中？如果您重复了测试，那么如果您改变了提供者的行为，那么您就有很多事情需要改变-而且您的测试将是脆弱的。如果您不重复测试，那么您的端到端测试就会卡在一个消费者中--如果您取消该消费者，那么就会出现丢失这些测试的所有问题。

对于纯契约测试，如果您添加了更多消费者已经理解的失败原因，那么（理想情况下）您不需要更改任何内容。

如果您尝试这样做，还有很多其他原因会让您头疼（您的测试开始严重依赖于精确数据，如果您的测试是端到端测试，失败的验证和can-i-deploy钩子的意义将会改变），但关键的是，Pact并不是作为端到端测试的替代而设计的。您可以这样使用它，但这是不可取的，而且很可能导致痛苦的维护。

您可以单独描述每个请求，使用Pact提供程序状态作为每个请求的先决条件。