当数据返回带有或不带有子代（填充或不存在现有数组）的项目时如何验证PACT

Question

我正在使用PACT和Java进行合同测试，而我的问题是我有一个API，其中的项目可能会像这样出现：

[
 {
  "programCode": "ELA_NGL_G7_TX",
  "contentResources": [
    {
        "tocPosition": 1827,
        "contentIdentifier": "l_6bf0783e-8499-4f6c-9f9b-c8fbdc8dcf6b_e5f25016-e2fa-4223-8969-2004c644917d"
    },
    {
        "tocPosition": 1828,
        "contentIdentifier": "l_192af774-54b9-4280-87e9-71f2b86a7d4d_e5f25016-e2fa-4223-8969-2004c644917d",
        "skills": [
            {
                "skillId": "ae836bd9-4758-4665-b3f8-8339313363e3",
                "spineId": "63c2b7d0-cd69-4e8a-9761-c90623104b8c"
            }
        ]
    }
]

如您所见，有时内部技能数组会出现其他情况，并且不确定如何将这种情况纳入我的消费者测试中。我的意思是，如果响应取决于特定的参数而具有或不具有技能阵列，则我可以进行两种不同的测试，这可能很好，但是此处它们来自同一调用。因此，我想我需要的是类似if if的东西，如果存在技能数组，那么我将断言其内部子元素，否则就忽略它。

这是我的消费者：

@ExtendWith(PactConsumerTestExt.class)
public class PublishContractWithTocGetSummaryTest {

Map<String, String> headers = new HashMap<>();

String getRecommendations = "/toc/getsummary/ELA_NGL_G7_TX";

@Pact(provider = "CRS-METADATA-FILTERING-SERVICE", consumer = "CRS-TOC-RECOMMENDER")
public RequestResponsePact createPact(PactDslWithProvider builder) throws IOException {

    headers.put("Content-Type", "application/json");

    DslPart body = new PactDslJsonBody()
            .stringValue("programCode", "ELA_NGL_G7_TX")
            .eachLike("contentResources")
                .integerType("tocPosition", 0)
                .stringType("contentIdentifier", "l_9d23cb4f-69dc-4032-bb53-73501234dc14_e5f25016-e2fa-4223-8969-2004c644917d")
            .closeArray();

    return builder
            .given("get TOC Summary")
            .uponReceiving("get TOC Summary")
            .path(getRecommendations)
            .method("GET")
            .headers(headers)
            .willRespondWith()
            .status(200)
            .body(body)
            .toPact();
}

非常感谢。

Answer 1

对于您的问题的简短回答是，没有一种方法可以完全按照您的意愿做。

关于为什么不可用的更长的答案在常见问题解答中：

为什么不支持指定可选属性？

首先，假定您在进行验证测试时可以控制提供者的数据（和消费者的数据）。如果您不这样做，那么契约可能是not the best tool for your situation。

[其次，如果Pact支持断言响应中可能存在元素$.body.name，那么您编写的消费者代码可以处理可选的$.body.name，但实际上，提供程序提供了$.body.firstname，因此不会进行测试永远不会告诉您您做错了一个假设。请记住，提供商可能会在不违反合同的情况下返回额外的数据，但它必须至少提供您期望的数据。

指定“ SOME_VALUE或null”也是如此。如果您的所有提供者验证测试数据都为此密钥返回空值，则您可能认为您已经验证了“ SOME_VALUE”，但实际上从未验证过。您在生产中可能会为此键获得完全不同的“ SOME_VALUE”，这可能会导致问题。

指定长度为0或更大的数组也是如此。如果所有提供者验证数据都返回长度为0的数组，则所有验证测试都将通过，而您无需验证数组的内容。这就是为什么您只能指定最小长度为1或零长度的数组的原因。

[请记住，与描述文档的所有可能状态的架构不同，Pact是“通过示例进行合同”。如果需要断言可能存在多个变体，则需要为每个变体提供一个示例。但是，在为每个变体添加Pact测试之前，请考虑它对您而言是否[重要]。请记住，每次交互都伴随着维护和执行时间的“成本”，因此您需要考虑在特定情况下是否值得付出这种成本。您可能最好处理契约中的常见情况，然后将您的使用者写成代码以优雅地处理意外的变化（例如，通过忽略该数据并发出警报）。https://docs.pact.io/faq#why-is-there-no-support-for-specifying-optional-attributes

Answer 2

所以，贝丝的答案是TL; DR：