So Pact won't support cases where a response has objects with EITHER an empty list or a list of length > 0. I cannot believe this isn't allowable , its a total deal breaker for using what is a great service. Great shame.

What happens in the case where your provider returns only empty lists and your validation passes and never returns a list greater than 0, and therefore cannot validator the object structure of a list with contents in it

You have a matcher that says its empty = OK or its got the objects I defined ? I don't see why thats a problem

See for a video explanation as to why

They can all be empty , they can all be length > 0 or either ? I think we are miscommunicating. Anyway its a big impediment to us using the framework /PactFlow so your team seem fixed on this approach. Maybe I am misunderstanding something but it doesn't seem like a good approach and doesn't allow us to use this.

Hmm, maybe we are 🙂 This is what I am thinking, rather than having one test Given there are no products (setup state to return empty list) When I make a request to get all products Then I am returned an empty list Given there are products (setup state to return populated list) When I make a request to get all products Then I am returned a list

Thanks for you help but perhaps I am not explaining the scenario correctly API response [ { "type": "parent", "children": [] #no children }, { "type": "parent" "children" :[{"name": "Buzz"}..... ] # children }, ..... ]

So if you had support for optional, during the pact verification you could get a result like

[
{
   "type": "parent",
   "children": []  #no children
},
{
    "type": "parent"
     "children" :[] #no children
},
.....
]

and your test would pass, and you would be safe to deploy. however your provider, when it has children could actually return a different structure than you expected for the list with children, and you wouldn’t know until it was too late?

[
{
   "type": "parent",
   "children": []  #no children
},
{
    "type": "parent"
     "children" :[{"firstName": "Buzz"}..... ] # children
},
.....
]

OK I see. What I was asking is can a matcher be implemented to verify an empty list or an object(s) like the one in the response but only that shape ? It appears not . I prefer to say either not optional , either no objects or the ones of a shape I define. Either one state or another, there's only two states. Like Enum isn't optional its one of a list of string s, does that make sense ?

I mean if developers cannot validate a response with this kind of structure Pact is very limited in its use , don’t you think ?

I don’t no, you can use provider states for this purpose.

I really expected for a paid for service this stuff would be covered off.

You’re asking for a fundamental change in a project, which has associated documentation to explain the rationale, so why would you assume that this would be covered?

Thanks is this part of the bidirectional testing approach here https://docs.pactflow.io/docs/bi-directional-contract-testing/ or can you send a link for me to find out more . Thanks for taking time out to assist me

yeah that is the one chap, you still utilise your existing pact contracts generated on the consumer side, and for the provider you upload an oas spec, plus verification results to show that the provider implements the specification. https://docs.pactflow.io/docs/bi-directional-contract-testing/contracts/oas#publishing-the-provider-contract--results-to-pactflow You can start with a plain text file or upload the OAS as the verification result file to get started quickly :)

The idea of Pact tests is that you can control the data coming back from your provider. Another option to test what you’re after is to do something like this:

[
    {
        "type": "parentwithnochildrcen",
        "children": []  #no children
    },
    {
        "type": "parentwithchildren",
        "children" :eachLike({"firstName": "Buzz"}) # children
    }
]

This would not match an arbitrary length array, but again, if you can control the data you now have tested both cases in a single test. If you can’t use provider states as Yousaf says, the

arrayContaining

matcher in JS might do what you need. It would allow you to specify multiple different object shapes, and would ensure the provider returns an array that at least has both of them. This is not yet available in Python though, which if I recall, is what you need

Thanks for all you help. if you have a moment and I know I have used alot of your time already , I see atLeastLike in the js version , this allows setting of the min length , would this allow an empty array (min=0) ?

Unfortunately we're still bound by the min=1 here also