目前我正在使用pact-jvm-consumer/provider-junit_2.11中的au.com.dius lib。让我的消费者协议工作并生成契约，但问题出现在我尝试在我的提供者服务中使用它们时
我们的想法是将所有协议与junit测试整合在一起，这样每个人都可以在本地运行他们的单元测试，而不必担心额外的协议测试。
主要问题是：
如何处理这个，假设在测试下的服务需要另一个服务（授权一个）和一个db作为数据馈送器。我不太相信每次在本地运行这些实例而不是杀死它们都可以解决问题。 （想要在将这些测试部署到任何环境之前进行测试）
是否应该使用某种“hack-switch”来处理，以便在“某些情况下”作为授权用户返回true，并模拟数据馈送器？或者应该以任何其他方式处理？
其次（附带问题）： 一旦我准备好了我的协议，我应该如何针对消费者测试这些？到目前为止，我得到的结果是:(效果很好，但我也不确定这些）
assertThat(result, instanceOf(DataStructure.class)); *as an example*
以上是为了确保我收到并推送给我的消费者的数据是我所期望的确切格式。这是正确的，或者正确的方法是打开所有这些并单独检查是否这些是例如地图或字符串
提前致谢！
答案 0 :(得分：0)
以下是关于验证期间存根服务的一些想法：
协议作者使用pact来测试微服务的经验是使用set_up钩子来填充数据库，运行pact：verify与所有真正的提供者代码一起工作得非常好，并让我们完全相信最终结束方案将在部署的代码中起作用。
但是，如果您有一个庞大而复杂的提供程序，则可能决定存根某些应用程序代码。您肯定需要对下游系统进行存根调用或设置错误方案。如果您存根，请确保您没有存根实际解析请求并将预期数据拉出的代码，因为否则消费者可能会发送绝对垃圾，并且协议：验证不会失败，因为该代码赢了不会被执行。如果在将记录插入数据源时进行验证，则不要存根，也不要重新考虑验证代码。
我个人会发布一个身份验证服务（假设你已经有一些其他测试来证明你正确地调用了身份验证服务）但我通常使用真正的数据库，除非这使得使用mock的事情变得更加“复杂” “（及时，努力，可维护性）。
关于你的第二个问题，我并不完全确定你在谈论什么，但我认为你正在谈论关于已经从模拟的响应中解组的对象的属性的断言（在消费者测试）。我会有一个检查每个属性的测试，以确保我在我的解组代码中使用了正确的属性名称。但正如我所说，我只会这样做一次（或者需要多次才能确保我已经检查过每个属性名称一次）。在其余的测试中，我只是断言返回了正确的对象类。