How to verify PACT when data returns items with or without children (filled in or no existing array)

I'm using PACT and Java for contract tests and my issue is that I have an api where the items may come up like this:

[
 {
  "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"
            }
        ]
    }
]

So as you can see, sometimes the inner skills array appears others it won't and not sure how to go about incorporating this scenario on my consumer tests. I mean, if the response had or no skills array depending on specific params, I could have two different tests and it might be fine, but here they come from the same call. So I guess what I need is something like an if else, that if the skills array is present then I would assert its inner children, otherwise just ignore it instead.

This is my consumer:

@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();
}

Many thanks.

Solution

The short answer to your question is that there isn't a way to do exactly what you want.

The longer answer about why that is not available is in the FAQs:

Why is there no support for specifying optional attributes?

Firstly, it is assumed that you have control over the provider's data (and consumer's data) when doing the verification tests. If you don't, then maybe Pact is not the best tool for your situation.

Secondly, if Pact supports making an assertion that element $.body.name may be present in a response, then you write consumer code that can handle an optional $.body.name, but in fact, the provider gives $.body.firstname, no test will ever fail to tell you that you've made an incorrect assumption. Remember that a provider may return extra data without failing the contract, but it must provide at minimum the data you expect.

The same goes for specifying "SOME_VALUE or null". If all your provider verification test data returned nulls for this key, you might think that you had validated the "SOME_VALUE", but in fact, you never had. You could get a completely different "SOME_VALUE" for this key in production, which may then cause issues.

The same goes for specifying an array with length 0 or more. If all your provider verification data returned 0 length arrays, all your verification tests would pass without you ever having validated the contents of the array. This is why you can only specify an array with minimum length 1 OR a zero length array.

Remember that unlike a schema, which describes all possible states of a document, Pact is "contract by examples". If you need to assert that multiple variations are possible, then you need to provide an example for each of those variations. Consider if it's really important to you before you do add a Pact test for each and every variation however. Remember that each interaction comes with a "cost" of maintenance and execution time, and you need to consider if it is worth the cost in your particular situation. You may be better off handling the common scenarios in the pact, and then writing your consumer to code to gracefully handle unexpected variations (eg. by ignoring that data and raising an alert).

https://docs.pact.io/faq#why-is-there-no-support-for-specifying-optional-attributes