Hey folks, another question on how to write a good contract test. We have a consumer that makes a call to retrieve a list of objects; it then iterates over the list of objects to find one with a matching name and proceeds to do whatever parsing/validation necessary on that particular object in the list. I realize this might not be the best interaction model to express in pact, and it would've been better to just call GET to retrieve that particular object, but it is what it is, unfortunately. I can talk to the service team to eventually change it. Still, I was wondering what would be the right way to model this in pact. Basically the contract is sorta: • return a list of objects of the same type • the list must contain one and only one object with name X, as described in the provider state • it can have more elements or just that one, consumer does not care And then we probably want to separately test the case when the consumer receives a list that does not contain the given element.

Is the name passed as a parameter in the request? Or is it a latent coupling that the contract couldn't definitely fulfil?

thanks! > Is the name passed as a parameter in the request? Or is it a latent coupling that the contract couldn't definitely fulfil? It is a latent coupling, unfortunately. How would my pact be different if it was explicit in the request? > You can use the

like

matchers (

atLeastOneLike

and others in JS, idk what language your consumer is in) to try to constrain the logic, but it's a bit hard to put strong reasoning around that kind of interaction. so how would I express something like

a list of items, each has a name field, and for one of them the name equals X, and that item matches the template, don't care about the others

? If I do something like:

EachLike(Map{"name": Equality("x")})

this means the provider can respond with a list that contains multiple items with the same name? Or should my consumer not care? > Ideally, fix the API up in future, so the client doesn't have to do the work itself (e.g. an endpoint that passes the name as a param, and gets back the expected entity, or a list if that makes more sense) agreed, this would be ideal, but idk if/when the api team can get to this

I don't think you can say "exactly one item matches this criteria, and no others do" with the Pact DSL

gotcha. Well, I don't think it matters much since I think the consumer code will pick the first one that matches anyway.

How would my pact be different if it was explicit in the request?

If an expected value in the response is supplied in the request, it's easier to demonstrate the coupling. Worst case, though, it can be coupled in the state description.

ah, so it's not about that pact can somehow match against the term in the request, but more like to make the pact more readable?

It's both. The contract describes the request and the response as a pair, so you can explicitly say that the request has a value that will be echoed somewhere in the response, e.g.

GET /lol/face?name=very-important-value

expects a response like

{
  "faces": [
    {
      "id": int(example: 3),
      "name": "very-important-value"
    }
  ]
}

isn't it the same with the provider state though? If we say

Given("very-important-value exists")

and expect the same response as above, isn't it the same?

it's very close, yes . . . not sure if it's exactly the same

I wonder if this is a good way to describe the contract:

{
  "faces": [
    {
      "id": int(example: 3),
      "name": "very-important-value"
    },
    {
      "id": int(example: 5),
       "name": string(example: 'whatever')
    }
  ]
}

with state like

given(very-important-value exists, among others)

(but structured)

Further: if it's just in the state name as a string, you don't have isolated access to it without parsing the string. If you put it in a param that's already parsed (e.g. path element, query param, or body value) then you can reuse it in the providers state implementation.

and have, as you suggested above, multiple test cases - with one, zero or multiple results

Yep, I think that's the starting point. Then you can champion the changes you want with these examples as supporting evidence 😎

yup, that's the plan. Tests like this can help make a case for API improvements

np, gl