-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Matching rules input / output mismatch #65
Comments
Update: The spec makes it seem intentional that that there is no secondary key underneath {
body: Pact::SomethingLike.new(foo: 'bar', alligator: { name: 'Mary' })
} translating to something like {
"body" => {
"$" => {
"matchers" => [ {"match" => "type"} ]
}
}
} What am I missing here? |
I'm sorry, v3 is only partially supported. It's a (slow) work in progress. |
The matching rules are not correctly serialised for v3 pacts as per the spec and progress will be tracked against the above linked issue. Thanks for the code pointers they will be helpful for anyone attempting to fix in the future as a side-note pact-js now uses the pact-reference project via ffi, and supports v3/v4 spec with the correct matching rules, so that should be solved for non ruby users. |
I am using pact specification version 3, and using multiple files to declare my interactions, as described here.
I've noticed that the matching rules are being lost for all interactions besides the last one to execute during my test suite. I've dug through the source code and the pact specification, and I think I found a discrepancy.
Pact Specification
The Jsonpath section of the specification seems to declare that
matchingRules
be a top level key forrequest
andresponse
, and thatmatchingRules
should then have keys that dictate what section of the request / response are being matched. It looks like Jsonpath takes over from there.Code
Pact::InteractionV3Parser.parse_request_with_non_string_body
takes care of nested matching rules, and line 45 indexes intorequest_matching_rules
with a key, e.g.body
. This is consistent with what the specification describes.The pact file I'm getting
Looks something like this:
Note that the
matchingRules
that are written here do not conform with the spec. I'm still reading through the code to find out where the contract gets written to the filesystem, but this seems to be the source of my problem. Can anyone confirm that this is a bug, or am I missing something?Local setup
npm packages:
gems (which come from
pact-node
)The text was updated successfully, but these errors were encountered: