【问题标题】:Pact provider test running app instancesPact 提供者测试运行应用程序实例
【发布时间】:2017-12-12 10:15:19
【问题描述】:

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

主要问题是:
如何处理这个问题,假设被测服务需要另一个服务(授权服务)和一个数据库作为数据馈送器。我不太相信每次在本地运行这些实例而不是杀死它们就可以了。 (甚至希望在将这些部署到任何环境之前执行测试)
这是否应该通过某种“hack-switch”来处理,以在“某些情况下”作为授权用户始终返回 true,并模拟数据馈送器?还是应该以其他方式处理?

其次(附带问题): 一旦我准备好我的协议,我应该如何针对消费者进行测试?到目前为止,我得到了类似的东西:(效果很好,但我也不确定这些)

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

以上内容是为了确保我收到并推送给我的消费者的数据与我所期望的格式完全相同。可以吗,或者正确的方法是打开所有这些并单独检查它们是否是例如地图或字符串

提前致谢!

【问题讨论】:

    标签: java junit pact


    【解决方案1】:

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

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

    pact 作者使用 pacts 测试微服务的经验是,使用 set_up 钩子填充数据库,并使用所有真实的提供程序代码运行 pact:verify 效果非常好,并且让我们完全相信最终结束场景将在部署的代码中工作。

    但是,如果您有一个庞大而复杂的提供程序,您可能会决定存根您的一些应用程序代码。您肯定需要存根调用下游系统或设置错误场景。确保,如果您存根,您不会存根实际解析请求并提取预期数据的代码,否则消费者可能会发送绝对垃圾,并且 pact:verify 不会失败,因为该代码赢了不要被处决。如果在您将记录插入数据源时发生验证,请不要存根任何内容,或者重新考虑您的验证代码。

    我个人会对身份验证服务存根(假设您已经进行了一些其他测试以表明您正在正确调用身份验证服务),但我通常使用真实数据库,除非这会使事情变得复杂,例如使用模拟“更便宜” "(在时间、精力、可维护性方面)。

    关于您的第二个问题,我不确定您在说什么,但我认为您是在对已从模拟响应中解组的对象的属性进行断言(在消费者测试)。我将进行一项检查每个属性的测试,以确保我在解组代码中使用了正确的属性名称。但正如我所说,我只会这样做一次(或者需要多次确保我检查了每个属性名称一次)。在其余的测试中,我只会断言返回了正确的对象类。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2017-04-20
      • 1970-01-01
      • 1970-01-01
      • 2021-12-13
      • 1970-01-01
      • 1970-01-01
      • 2020-09-29
      相关资源
      最近更新 更多