契约提供者测试的范围应该是什么？

Question

大约半年前，我的组织开始使用Pact来创建/验证用Java编写的REST服务/微服务之间的合同。 我们很难决定提供商测试的适当范围或把握应该是什么，并且会喜欢其他协议用户的经验。

基本上，讨论围绕提供程序测试中的mock / stub的位置进行演变。 在服务中，您必须至少模拟对其他服务的外部调用，但您也可以选择模拟更接近REST资源类。

我们将其归结为两种选择：

1.第一个选项是提供者测试应该是严格的合同测试，并且只运行提供者服务的REST资源类，模拟/删除从那里使用的服务类/协调器等。 此合同测试将通过组件测试进行扩充，该组件测试将测试由提供程序测试存根/模拟的部件。

2.第二个选项是使用提供程序测试作为组件测试，该测试将为每个请求执行整个服务组件。 只有对其他组件的传递外部调用才会被模拟/存根。

这些是每个选项的专业人士的想法

选项1的专业版：

• 测试将更容易实施，并将占用更小的空间
  =>更高的隔离度。
• 我们可能还需要其他组件测试来涵盖消费者期望中通常未涵盖的用例（错误流等）。 这样我们就不会在一个包中混合使用不同类型的组件测试（Pact和其他），使测试套件更容易理解。

选项2的专业版：

• 测试正在运行更多的“真实”代码=>由于糟糕的模拟/存根而导致测试错误的风险降低。

我真的很想知道您的提供商测试通常在这方面的看法。 有最好的做法吗？

澄清“组件”的含义：组件是微服务或更大服务应用程序中的模块。 我们采用了来自Martin Fowlers的组件的定义http://martinfowler.com/articles/microservice-testing/ 。

提供者服务/组件通常在Jersey资源类中具有REST端点。 此端点是Pact提供程序测试的提供程序端点。 一个例子：

@Path("/customer")
public class CustomerResource {

    @Autowired private CustomerOrchestrator customerOrchestrator;

    @GET
    @Path("/{customerId}")
    @Produces(MediaType.APPLICATION_JSON)
    public Response get(@PathParam("customerId") String id) {
        CustomerId customerId = CustomerIdValidator.validate(id);
        return Response.ok(toJson(customerOrchestrator.getCustomer(customerId))).build();
    }

在上面的示例中，@ Aututired（我们使用spring）CustomerOrchestrator可以在运行提供程序测试时进行模拟，也可以注入真正的“Impl”类。 如果您选择注入真正的“CustomerOrchestratorImpl.class”，它将具有额外的@Autowired bean依赖项，而这些依赖项又可能具有其他...等等。最后，依赖项将最终出现在将进行数据库调用的DAO对象中，或者一个REST客户端，它将对其他下游服务/组件执行HTTP调用。

如果我们在上面的例子中采用我的“选项1”解决方案，我们将模拟CustomerResource中的customerOrchestrator字段，如果我们采用“选项2”，我们将为CustomerResource中的每个依赖项注入Impl类（真实类）依赖图并创建模拟的数据库条目和模拟下游服务。

作为旁注，我应该提一下，我们很少在提供程序测试中实际使用真正的数据库。 在我们采用“选项2”的情况下，我们模拟了DAO类层，而不是模拟实际的数据库数据，以减少测试中移动部件的数量。

我们创建了一个“测试框架”，可以自动模拟任何未在spring上下文中显式声明的Autowired依赖项，因此stubing / mocking对我们来说是一个轻量级的过程。 这是运行CustomerResource并启动存根的CustomerOrchestrator bean的提供程序测试的摘录：

@RunWith(PactRunner.class)
@Provider("customer-rest-api")
@PactCachedLoader(CustomerProviderContractTest.class)
public class CustomerProviderContractTest {

    @ClassRule
    public static PactJerseyWebbAppDescriptorRule webAppRule = buildWebAppDescriptorRule();

    @Rule
    public PactJerseyTestRule jersyTestRule = new PactJerseyTestRule(webAppRule.appDescriptor);

    @TestTarget public final Target target = new HttpTarget(jersyTestRule.port);

    private static PactJerseyWebbAppDescriptorRule buildWebAppDescriptorRule() {
        return PactJerseyWebbAppDescriptorRule.Builder.getBuilder()
            .withContextConfigLocation("classpath:applicationContext-test.xml")
            .withRestResourceClazzes(CustomerResource.class)
            .withPackages("api.rest.customer")
            .build();
    }

    @State("that customer with id 1111111 exists")
    public void state1() throws Exception {
        CustomerOrchestrator customerOrchestratorStub = SpringApplicationContext.getBean(CustomerOrchestrator.class)
       when(customerOrchestratorStub.getCustomer(eq("1111111"))).thenReturn(createMockedCustomer("1111111));

    }
    ...

Answer 1

这是一个经常出现的问题，我的回答是“为每项服务做有意义的事情”。 使用pact的第一个微服务非常小而且简单，只需要测试整个服务而没有任何模拟或存根是最容易的。 调用真实服务和验证测试中的调用之间的唯一区别是我们使用sqlite进行测试。 当然，我们扼杀了对下游服务的呼叫。

如果设置真实数据比存根更复杂，那么我会使用存根。 但是 ！ 如果要执行此操作，则需要确保以与pact相同的方式验证存根调用。 使用某种共享夹具，并确保对于您在pact提供程序测试中存根的每个调用，您都有一个匹配的测试，以确保行为符合您的预期。 就像你将协作/合同测试链接在一起一样：

Answer 2

我说选择2。

原因是因为Pact的整个存在理由是对你的代码变更有信心 - 这不会打破消费者，或者如果确实如此，找到一种方法来管理这种变化（版本控制），同时仍然保持相互作用完整。

要充分自信，您必须使用尽可能多的“真实”代码，而数据可以是模拟的或真实的，在这一点上并不重要。 请记住，您希望能够在部署之前测试尽可能多的生产代码。

我使用它的方式，我有两种类型的测试，单元测试和契约测试。 单元测试确保我的代码不会破坏愚蠢的错误或错误的输入，这对于模拟依赖项很有用，而Pact测试用于测试使用者和提供者之间的交互以及我的代码更改不会影响请求或数据格式。 您可能会在此处模拟依赖项，但这可能会使生产中断，因为该依赖项可能会影响请求或数据。

最后，只要您使用它来测试消费者和提供者之间的合同，就可以优先考虑如何使用Pact。

Answer 3

我们决定选项2.我们应该努力在提供商测试中包含尽可能多的实际代码。 主要原因是，在补充组件测试中通过模拟弹簧bean实现测试对称性将比使用选项2导致稍微更复杂的提供者测试更复杂。

感谢您的投入！