pact-foundation
Change the request and response validation to use paths mapped to matchers
The current validation of the requests and response bodies is by comparison of the whole expected body. It does allow more to be in the actual body, but it is awkward when the bodies get large.
One idea id to allow paths to be mapped to a matcher. This would work in a XPath or JSON Path style. That way you can have a number of paths to execute the matcher against.
Not sold on this idea, I think it would be even more awkward to specify matcher for every value than to specify a large hash. Imagine
$person.address.street => "...",
$person.address.suburb => "...",
$person.address.postcode => "...",
$person.address.state => "...",
$person.address.country => "...",
vs
{ "person" :
{ "address" : {
"street: "...',
"suburb: "...',
"postcode": "...',
"state": "...',
"country": "...' }
}
This is a simple example, but imagine some deeply nested hashes - you'd have to repeat the full path to each node for each value, which would end up much more typing than just specifying a hash. Using a hash, you also get the benefit of human readable documentation - the JSON is much more communicative than json paths, in my opinion.
Maybe I've misunderstood what you mean though?
We want the comparison to be composable. So for your example, we would do something like:
"/organisation/person" => {
"address" : {
"street: "...',
"suburb: "...',
"postcode": "...',
"state": "...',
"country": "...' }
}
},
"//product" => {
...
}
That may we're only validating the subset of the document we're interested in. For JSON it may not make much sense, but when you have a SOAP based service, you want to skip all the SOAP junk.
You make a good point about the SOAP. Paths do make more sense for XML.
Generating the mock response would be a bit trickier though - would we put a product node in the top level of the response in your example above?
No, the // means anywhere in the document.
The response for the client would have to be generated somehow. Maybe in a similar way to the Pact Terms.
Maybe we should look at how Brent is thinking of doing it in his project because he wants to do something similar.
Yeah, I get the double slash - we'd have to pick an arbitrary place to put the hash in in the response though, which would be tricky. Deterministic/random? Good idea about talking to Brent.
We should also bare in mind all the XML junk around namespaces and attributes. Do we validate using a query that contains that complexity (//v123:order[@type='online']) or by some simple query with a chunk of XML as a value? The more complex the query, the harder it would be to do any automagic generation of a response.
Closing this as matching based on the 2.0 spec has been implemented
https://github.com/pact-foundation/pact-specification/tree/version-2?tab=readme-ov-file#supported-matchers
