Pact-js: when eachLike is used with the Like matcher, it compares any field as opposed to a specific field

[paprende]

when you add an interaction like this

provider.addInteraction({
  state: 'foobar',
  uponReceiving: `a request for a foo request`,
  withRequest: {
    method: 'GET',
    path: 'foo',
  },
  willRespondWith: {
    status: 200,
    body: {
      foo: eachLike(like({ bar: 'foobar' }))
    }
  }
});

the pact file will give us

...
"matchingRules": {
  "$.body[0].foo[*].*": {
    "match": "type"
  },
  "$.body[0].foo[*].bar": {
    "match": "type"
  },
}
...

However I want the pact file to look like this

...
"matchingRules": {
  "$.body[0].foo[*].bar": {
    "match": "type"
  },
}
...

Currently the pact file will compare any number of items in the array with any field. However, I want to compare to any number of items in the array with a specific field.

As a result, when verifying against a provider that returns extra fields that I'm not concerned with my expectation will fail.

I really love this tool and any help will be appreciated

Regards

[bethesque]

You don't need the inner like for starters. Let me get my head around the rest.

[bethesque]

@mefellows I've noticed a few people nesting the likes. We should update our docs to indicate that it's unnecessary. Once you've put a like on a parent object, all children will be treated as like.

[bethesque]

@paprende I'm sorry, I can't work out what you're trying to do. Can you provide me with an example that you want it to match, and an example that you want it to fail?

[mefellows]

Thanks Beth. I've seen an issue like this before and will try to dig it up - I thought we supported this use case.

I think what's happening is that from a consumer perspective let's say all you care about is:

[{
  "foo": "bar"
}] 

But when the provider verification happens, it fails because of baz:

[{
  "foo": "bar",
  "baz": "bat"
}] 

I'll try to repro.

@paprende if you can please provide logs/stacktraces etc. that'd be great.

[bethesque]

That should not be the case. Something is going wrong, because it's definitely not supposed to do that.

[bethesque]

This e2e example passes:

https://github.com/pact-foundation/pact-ruby-e2e-example/blob/master/consumer/spec/bar_spec.rb#L19

factories: Pact.each_like(location: "Sydney", capacity: 5)

https://github.com/pact-foundation/pact-ruby-e2e-example/blob/master/provider/bar_app.rb#L7

"factories": [{
    "location": "Sydney",
    "capacity": 5
},
{
    "location": "Sydney",
    "geographicCoords": "-0.145,1.4445",
    "capacity": 5,
}]

[paprende]

@mefellows yes this is exactly the issue I having at the moment.

[mefellows]

I've just pushed a branch repro/issue-60 that demonstrates what you're asking for with no issues.

If you clone the repo with this branch and do the following:

npm i
cd examples/e2e
npm test:consumer
npm test:publish
npm test:provider

The verification should pass.

The consumer tests expect:

          {
            "id": 1,
            "first_name": "Billy",
            "animal": "goat",
            "age": 21,
            "gender": "M",
            "location": {
              "description": "Melbourne Zoo",
              "country": "Australia"
            },
            "eligibility": {
              "available": true,
              "previously_married": false
            },
            "interests": [
              "walks in the garden/meadow"
            ]
          }

But the provider returns more (location.post_code and thisisnewfield):

  {
    "first_name": "Billy",
    "last_name": "Goat",
    "animal": "goat",
    "age": 21,
    "gender": "M",
    "thisisnewfield": "aoeu",
    "location": {
      "description": "Melbourne Zoo",
      "country": "Australia",
      "post_code": 3000
    },
    "eligibility": {
      "available": true,
      "previously_married": false
    },
    "interests": [
      "walks in the garden/meadow",
      "munching on a paddock bomb",
      "parkour"
    ]
  }

[paprende]

Thanks @mefellows I will give that a try. Just to note. I'm using pact-jvm for the verification side.

[mefellows]

Aha! Perhaps start with Beth's suggestion of removing the nested matching rules and just leaving the object wrapped in eachLike and see how that goes.

If you're still seeing issues, it's sounding like we'll need to raise a defect over at Pact JVM.

@uglyog - does this issue ring any bells for you?

[uglyog]

Don't think this is a verification issue, the double like seems to be generating the matchers as expected (for double likes).

[paprende]

@mefellows thank yes I can confirm your example works. In my provider the extra field return is null so I tried changing thisisnewfield to null and the spec still passes. @uglyog will null values work with pact-jvm?

[uglyog]

Nulls should be ok, as long as they are not expected fields or the expected value is null.

[bethesque]

Allowing extra values in the response has been in every implementation since forever. Something else must be going wrong, because everyone using the JVM implementation would have come across this before now.

[bethesque]

@paprende can you please provide an executable example of your failure? Please make a branch for the javascript to create the pact, as Matt has above. Check the pact in, and then make a branch from one of the JVM examples, using the git URL of the pact.

[bethesque]

How is this going @paprende?

[paprende]

@bethesque I'm going to try the suggestions from everyone as it most likely an issue on my side. If I do have more problems I will create a branch as you have suggested.

[bethesque]

Ok! I'm going to close this for now, but feel free to reopen it if you have further issues.