The ability to generalise what we expect from an array about pact-specification

[thetrav]

Is the large data set fundamentally part of the response? I would look into constructing a test state where less data needed to be transmitted (assuming that scenario still makes sense to the provider)

[bethesque]

Pact really works best when you are able to set up data on the provider yourself (provider states). It's not the best tool for using with an API where you don't control the data (as it sound like you aren't). Check out some docs about that here: https://github.com/realestate-com-au/pact/wiki/Why-Pact-may-not-be-the-best-tool-for-testing-public-APIs

Having said that, in version 2 matching, we are looking at adding the ability to specify "an array of > 1 length, where all items match this pattern". I don't imagine that will be available within the next few weeks however.

[uglyog]

I think this would be very useful. I find one of the big issues I experience is the coupling of the consumer test data to the provider ones.

An example: I have a User provider that provides lists of users. The contract would be to retrieve a list of users. It is more important that I get a list of at least one user, and that all users I get back conform to my contract.

I find with provider states I have to create fixtures that are shared between the consumer tests and the provider tests which creates a form of coupling. If someone updates the fixture in one project, they have to know to go through every project and do the same update. If the condition was less strict, you could update the fixture in the provider to change the number of entities and all the consumer tests would still work.

[uglyog]

Here is my thoughts on the at_least rule:

at_least(3, number) means at least 3 numbers, but all elements must be numbers.
at_least(3, 'red') means at least 3 reds.
at_least(1, { "name": "Bob"}) means 1 or more objects, but they all have to have a name field with value bob.

[bethesque]

From comment in example:

I don't like the idea of specifying a type with a name, because then we have to agree across all implementations in all languages what each type means. Specifying by example is the pact way so far, and I'd like to continue with it.

I think at_least([1, 2, 3]) should mean "an array starting with 1, 2, 3".
I think at_least(['red', 'red', 'red']) isn't a scenario that's likely to be useful - why would you ever have three of the same thing in a row?
I think some({"name": "Bob"}) is the most likely scenario, and should mean 'at least one where all the elements match by type.'

Edit: I think some({"name": "Bob"}) is the most likely scenario, and should mean 'at least one item, where all the elements in the list match by type.'

[uglyog]

I don't think 'at least one where all the elements match' is the most likely, I think it is 'at least one in the list, and all the items in the list must match'. That is the case that @mortenlj gave.

[bethesque]

Sorry, I phrased it badly, that is what I meant.

[uglyog]

I think I have worked out a way to implement this. We can add an at_least matcher that takes a minimum number and a single example (or a single definition with matchers). It will add then add the following to the matchers for the given definition:

// example in groovy-like language
example_consumer_body {
    users atLeast(2) {
        name matchString
        age matchNumber
        id identifier
    }
}

Resulting matchers:

{
  "$.body.users": {"at_least": 2},
  "$.body.users.$all.name": {"match": "string"},
  "$.body.users.$all.age": {"match": "number"},
  "$.body.users.$all.id": {"regex": "[0-9]+"},
}

This means we expect a list with at least 2 elements, but all elements must match the given rules. We can have a similar behaviour for at_most.

This will work until somebody has an API with $all as a key. We can also use a * to mean all, but then someone could also use * as a key! :-P

For the case of some, I would prefer the use of any, but it can support both. So we could have: at_least, at_most, any and all.

[bethesque]

For the type based matching, I was envisioning something like:

body: something_like(
  name: "Fred",
  age: 9
)

becomes

{
  "$.body.*" : {"match": "type"}
}

That could be reused in this case:

{
  "$.body.users": {"at_least": 2},
  "$.body.users.*": {"match": type}
}

It has less duplication, and instructs the matcher how to use the example to match to the real thing, rather than specifying what the expected thing should be.

[uglyog]

The following test cases have been added for this feature:
testcases/request/body/array size less than required.json
testcases/request/body/array with at least one element matching by example.json
testcases/request/body/array with at least one element not matching example type.json
testcases/request/body/array with nested array that does not match.json
testcases/request/body/array with nested array that matches.json
testcases/request/body/array with regular expression in element.json
testcases/request/body/array with regular expression that does not match in element.json

[mortenlj]

Hi. I'm going over my old issues and PRs on github and "cleaning up". From what I can gather, this was eventually included in the v2 specification, wasn't it?

I moved on to other projects some years ago, so I never got around to actually trying to use the requested feature. I'm closing the issue, feel free to re-open if it should be kept.