when eachLike is used with the Like matcher, it compares any field as opposed to a specific field about pact-js HOT 18 CLOSED

@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.

from pact-js.

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

from pact-js.

@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?

from pact-js.

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.

from pact-js.

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

from pact-js.

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,
}]

from pact-js.

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

from pact-js.

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"
    ]
  }

from pact-js.

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

from pact-js.

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?

from pact-js.

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

from pact-js.

@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?

from pact-js.

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

from pact-js.

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.

from pact-js.

@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.

from pact-js.

How is this going @paprende?

from pact-js.

@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.

from pact-js.

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

from pact-js.