java Pact提供程序测试运行应用程序实例

Question

目前我正在使用来自au.com.dius lib的pact-jvm-consumer/provider-junit_2.11。让我的消费者契约生效并生成契约，但当我尝试在我的提供商服务中使用这些契约时，问题就出现了
其想法是使所有的pact与junit测试集成在一起，这样每个人都可以在本地运行他们的单元测试，而不用担心额外的pact测试

主要问题是：
如何处理这个问题，假设测试中的服务需要另一个服务（授权服务）和一个db作为数据馈线。我不太相信每次在本地运行这些实例并杀死它们都能奏效。（希望在将其部署到任何环境之前执行测试）
作为“某些情况下”的授权用户，是否应该使用某种“黑客开关”来处理此问题，以始终返回true，并模拟数据馈送器？还是应该以其他方式处理

第二（附带问题）： 一旦我准备好协议，我应该如何针对消费者测试这些协议？到目前为止，我得到了如下结果：（效果很好，但我也不确定这些）

assertThat(result, instanceOf(DataStructure.class)); *as an example*

以上是为了确保我收到并推送到我的消费者的数据的格式与我所期望的完全一致。这样可以吗，或者正确的方法是将所有这些文件解包，并分别检查它们是否为地图或字符串

提前谢谢

Answer 1

以下是关于验证期间存根服务的一些想法：

https://github.com/pact-foundation/pact-ruby/wiki/FAQ#should-the-database-or-any-other-part-of-the-provider-be-stubbed

The pact authors' experience with using pacts to test microservices has been that using the set_up hooks to populate the database, and running pact:verify with all the real provider code has worked very well, and gives us full confidence that the end to end scenario will work in the deployed code.

However, if you have a large and complex provider, you might decide to stub some of your application code. You will definitely need to stub calls to downstream systems or to set up error scenarios. Make sure, if you stub, that you don't stub the code that actually parses the request and pulls the expected data out, because otherwise the consumer could be sending absolute rubbish, and the pact:verify won't fail because that code won't get executed. If the validation happens when you insert a record into the datasource, either don't stub anything, or rethink your validation code.

我个人会存根一个身份验证服务（假设您已经有一些其他测试来证明您正确地调用了身份验证服务），但我通常使用真实的数据库，除非这会使事情复杂化，以至于使用mock“更便宜”（在时间、精力、可维护性方面）

关于你的第二个问题，我不太清楚你在说什么，但我认为你在说的是对从模拟响应（在消费者测试中）中解包的对象的属性进行断言。我将有一个测试来检查每个属性，以确保在解组代码中使用了正确的属性名称。但正如我所说的，我只会这样做一次（或者不管我检查每个属性名需要多少次）。在其余的测试中，我只声明返回了正确的对象类