Feature request - `array_contains` or `each_like` with multiple elements

[ivawzh]

Say I want to talk to a service to create a pony. We know the response will be:

  {
     id: 1,
     history: [
       { event: "create", date: "01-01-2000", id: 123 },  
       { event: "health_check", date: "01-01-2000", id: 124 },  
       { event: "verify", date: "01-01-2000", id: 125 },  
       { event: "approve", date: "01-01-2000", id: 126 }
     ]
  } 

However, I only care IDs of two particular events - create and approve.

So my Pact is:

expected_response = {
  id: Pact.like(123),
  history: [
    {
      event: 'approve',
      id: Pact.like(2)
    },
    {
      event: 'create',
      id: Pact.like(1)
    }
  ]
}

Note I don't even care the order within the history array.

This Pact setup won't work because Pact will try to exact match on history array. And then it will complain about array order and length not match.

The current each_like method only accepts one element.

I think the ideal scenario will be having a new matcher called array_contains which allow us to match and generate multiple elements in an array; and ignore array length and order.

[mefellows]

You can still wrap the entire array in a like and I believe you can additionally restrict the value of event in history to approve and create using a regex. What you can't do at the moment is ask pact to validate that it contains exactly two elements within the array of n elements.

[ivawzh]

@mefellows If I use regex with a union value like:

expected_response = {
  history: Pact.like([
    {
      event: Pact.term(
        generate: 'approve', 
        matcher: /(approve|create)/)
      }),
      id: Pact.like(2)
    },
    {
      event: Pact.term(
        generate: 'create', 
        matcher: /(approve|create)/)
      }),
      id: Pact.like(1)
    }
  ]
})

It will fail for:

• array length not matched
• the second element in the actual response is neither approve or create.

For now, a dirty hack around would be:

expected_response = {
  history: Pact.like([
   {
      event: Pact.term(
        generate: 'create', 
        matcher: /(approve|create|health_check|verify)/)
      }),
      id: Pact.like(1)
    },
    {
      event: Pact.term(
        generate: 'Dont mind me. I am a placeholder for making length check pass.', 
        matcher: /(approve|create|health_check|verify)/)
      })
    },
    {
      event: Pact.term(
        generate: 'Dont mind me. I am a placeholder for making length check pass.', 
        matcher: /(approve|create|health_check|verify)/)
      })
    },
    {
      event: Pact.term(
        generate: 'approve', 
        matcher: /(approve|create|health_check|verify)/)
      }),
      id: Pact.like(1)
    }
  ]
})

Ugly because consumer has to

1. know all the possible event names, though I only care two of them,
2. fill with placeholders because of array length check.

Furthermore, it will give me false positive if the actual response contains 4 verify events. Also if provider changes to provide 7 events, test will be broken though consumer is not actually affected.

[bethesque]

If you were to design the interface for this, what would you want it to look like, and what should it's pass/fail scenarios be?

[ivawzh]

For my current case, we only need something like

{
  history: Pact.array_contains(
    { event: 'create', id: Pact.like(1) }, 
    { event: 'create', id: Pact.like(1) }
  )
}

If I am greedy, I imagine it'd be good to also have

• array_contains_either
• array_contains_any
• array_contains_none
• aggregator:

  Pact.arrayThat(
    contains_either: [{ gender: 'male' }, { gender: 'female' }],
    contains_any: [{ origin: 'Australia' }, { origin: 'China' },  { origin: 'India' }]
    contains_none: [{ speak: 'Martian' }],
  )

But array_contains is really the only and urgent feature we need for now in many places.

[bethesque]

I've been giving this some thought.

What should we do in the scenario where an element exists in an array that doesn't have an example specified for it?

expected = Pact.array_contains "red", "green"
actual = ["blue", "red", "green"]

Do we match blue based on type? Do we ignore it completely? It makes me a little nervous to be just ignoring elements, but I guess that's what the consumer is doing anyway.

With the contains_any, this asserting doesn't assert much. If all the elements come back as Australia, then we may still think that China and India are options when they may not be. I don't like the idea of making an assertion that is un-assertable. I guess it's the same as doing a regex Australia|China|India though, and that's already allowed. It just makes me uncomfortable. I wonder if we could have a warning for options that are never found.

One thing is that pact doesn't provide a "does not contain" assertion. This is for a few reasons. One, as each interaction contract only applies to one interaction, you can never be assured that a different request/response pair might not have the thing you are asserting doesn't exist. Secondly, just because you don't use a thing, doesn't mean another consumer doesn't want a thing. Being allowed to say "x has a thing" and "x does not have a thing" would lead to potential conflicts. Following Postel's law means a consumer should be relaxed about what it accepts, and ignore things that don't apply to it.

I understand this is a little different when we're talking about array elements rather than json nodes, however, I still feel it would be a bad feature choice.

Sorry, this is a lot of nit picking, but thinking through all the positive and negative implications of a feature is part and parcel with the specification design! It's gotta be done.

[uglyog]

The issue is when people have lists with key value pairs, there can be any number but they are only interested in some of them. See pact-foundation/pact-jvm#378

[ivawzh]

I actually did not give too much thought before I mention array_contains_either, array_contains_any, array_contains_none. I agree with @bethesque, maybe in most of the common cases we should use context (given and upon_receiving) to help setup response instead of having array_contains_either, array_contains_any, array_contains_none to declare general response types. Some examples:

# example for array_contains
# the provider will stub some things to make sure at least one girl will be created. 
stubbed_service
  .given('I hope there will be at least one girl')
  .upon_receiving('make me 12 ponies')
  .will_respond_with(
    Pact.array_contains({ name: Pact.like('Bell'), gender: 'girl' })
   )

# example for array_contains_none
# the provider will stub some things to make sure all girls. 
stubbed_service
  .given('I hope there will be no boys')
  .upon_receiving('make me 12 ponies')
  .will_respond_with(
    Pact.each_like({ name: Pact.like('Bell'), gender: 'girl' })
   )

# example for array_contains_any
# the provider does not need to be stubbed. 
stubbed_service
  .given('boy or girl is up in the air')
  .upon_receiving('make me 12 ponies')
  .will_respond_with(
    Pact.each_like({ 
      name: Pact.like('Bell'), 
      gender: Pact.term(
        generate: 'girl', 
        matcher: /(boy|girl)/)
      })
    })
   )
)

I think in the array_contains_any example the consumer test will be a bit hacky because the generated array will only contain girl in this setup. Thus it cannot test if downstream logics can properly handle boy and girl at the same time. But it's a minor issue.

Contains_either is implying when one type occurs then the other type won't occur. That's effectively a 'does not contain' assertion. Hence we don't need to consider.

[TimothyJones]

array_contains would have been useful on our last project - for modelling a set of returned elements, we don't necessarily know the order that they'll come in.

I agree with the arguments against array_contains_any and array_contains_none

[uglyog]

I think the solution to this problem is to be able to apply matchers based on a predicate (See pact-foundation/pact-jvm#727)

For example:

validatedAnswers minLike(1) {
  when(type == ''typeA") {
    favourite_colour regex('blue|red')
    ...
  }
}

This should add a type matcher something like (see what I did there? ;-) )

    "matchingRules": {
          "body": {
            "$.validatedAnswers": {
              "matchers": [
                {
                  "match": "type",
                  "min": 1
                }
              ],
              "combine": "AND"
            },
            "$.validatedAnswers[*].favourite_colour": {
              "matchers": [
                {
                  "match": "regex",
                  "regex": "red|blue"
                }
              ],
              "combine": "AND",
              "predicate": [
                "$.validatedAnswers[@].type == 'typeA'" // this need to be related to the same array item somehow
              ]
            }
          }
        }

[mefellows]

This should add a type matcher something like (see what I did there? ;-) )

🙄 I like the concept of a predicate, it would simplify many of the polymorphic payloads I see around the place. I'll add a note to review the latest OAS specification that deals with these types of variants, as it could be useful in being fully across for v4 of the spec.

…

On Sun, Aug 12, 2018 at 1:33 PM, Ronald Holshausen ***@***.*** > wrote: I think the solution to this problem is to be able to apply matchers based on a predicate (See pact-foundation/pact-jvm#727 <pact-foundation/pact-jvm#727>) For example: validatedAnswers minLike(1) { when(type == ''typeA") { favourite_colour regex('blue|red') ... }} This should add a type matcher something like (see what I did there? ;-) ) "matchingRules": { "body": { "$.validatedAnswers": { "matchers": [ { "match": "type", "min": 1 } ], "combine": "AND" }, "$.validatedAnswers[*].favourite_colour": { "matchers": [ { "match": "regex", "regex": "red|blue" } ], "combine": "AND", "predicate": [ "$.validatedAnswers[@].type == 'typeA'" // this need to be related to the same array item somehow ] } } } — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#38 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADSjAJnDlliS_4oB6HzfxLg9W1Aokr7ks5uP6ILgaJpZM4OGJxv> .

-- Matt Fellows - http://www.onegeek.com.au/