Comments (16)
disagree
from pact-specification.
@edanielsen, we're currently writing a pact specification, and going through each part of the request to work out what the matching rules should be. Having done a bit of poking around on the internet about the query string, I'm not entirely sure that we can say that order should not matter. For example, if you have two parameter with the same name, they essentially become an array, and order COULD matter.
from pact-specification.
However, there are a set of feature requests with a similar theme, all around being less strict on the request.
Assuming we want to allow for non-strict requests (which is not necessarily the case) we could consider adding some more metadata for v2 of pacts.
- Allow different order of query params, or additional parameters
- Allow all sorts of madness in the headers (the javascript guys have a lot of trouble there with cookies and CSRF flags)
- Allow extra junk / regexes in the request body
So it wouldn't be the default, but could be switched on in the DSL for specific pacts.
While I'm somewhat opposed to it on phillosophical grounds, I don't feel it's appropriate to use that as a factor in the decision.
The important factor would be the cost of increased complexity in the matchers for each language
from pact-specification.
I'll probably repeat myself as I've mentioned similar idea in the related issue but here it goes.
Based on current philosophy of being strict by default what if you leave the current implementation and call it strict mode. All marchers in every language should at least implement the strict mode.
Then, in contract json there could be some kind of options array which will have ignore_paremeter_order: true and other matcher options. Each matcher implementation should be able to tell which options it supports and if a matcher in e.g. Python doesn't support ignoring of parameter order due to some std lib python constraint( just making things up) it will throw exception(or print warning) if user gives it a contract with options it can't handle.
Thoughts ?
from pact-specification.
Here is a gist of a way I've been thinking of to serialise matching information about the pact file, for pact-specification 2. https://gist.github.com/bethesque/5a35a3c1cb9fdab6dce7
The option that you speak of could go in the responseMatchers section.
from pact-specification.
@uglyog If we are going to make the order not important for one implementation, then we need to do it for all implementations, and make them consistent, and part of the pact-specification.
Two things
- you can have the same parameter specified multiple times, so a hash is not the right data structure to represent the parameters.
- sometimes the ordering of params could be important, for example, when representing an array. ?blah=thing1&blah=thing2&blah=thing3
from pact-specification.
A map of key -> array of values would retain the order of values, so:
blah=thing1&blah=thing2&blah=thing3 would become Map(blah -> [thing1, thing2, thing3])
In my example, the query strings q=p&q=p2&r=s
and r=s&q=p&q=p2
would be equal because they will have the following structure:
Map(q -> [p, p2], r -> [s])
while q=p&q=p2&r=s
and q=p2&q=p&r=s
would not because
Map(q -> [p, p2], r -> [s]) != Map(q -> [p2, p], r -> [s])
I like the idea of @Maxim-Filimonov in having a strict versus non-strict mode, where strict mode compares the actual query string, while non-strict compares using the map structure.
from pact-specification.
Map with arrays makes sense, and addresses the 95% usecase of "ordering of different named params doesn't matter, but ordering of the same named params does".
Got ideas on how to DSL and serialize the strict versus non-strict modes?
from pact-specification.
I am personally inclined to just do the structure matching on the map of arrays, and not support strict mode. I think needing to specify the order of differently named params is such a corner case that there's probably little value in supporting it. Most frameworks don't even retain the order, as params are generally exposed as a hash.
from pact-specification.
@bethesque correct me if i'm wrong but I think in rails the order of parameters matter for array composition. For example, arr[]=1&arr[]=2
gives you params[arr] = [1,2]
while arr[]=2&arr[]=1
gives you params[arr] = [2,1]
. So i'm not sure how much of corner case is that, Rails is quite popular framework after all.
from pact-specification.
I agree - what I was saying was that order does matter when the params have the same name, but order does not tend to matter between params with different names.
So arr[]=1&arr[]=2&foo=bar
should be considered a match for foo=bar&arr[]=1&arr[]=2
, but not a match for arr[]=2&arr[]=1&foo=bar
from pact-specification.
ah my bad - misunderstanding is my second name 🚼
👍 on ignoring order for differently named params. If someone comes up with a compelling case where it does matter we can come back to this discussion and than do multiple modes.
from pact-specification.
Having decided that we want to allow flexible ordering of params, except when the params have the same name, it makes sense for v2 to allow the params to be specified in a hash in the consumer DSLs, and to be serialised as a hash in the pact json.
some_provider.upon_receiving("a request for something").with(
path: "/something",
query: {
"param1" : like("blah"),
"param2" : [ eg("123", /\d{3}/), eg("456" /\d{3}/ ]
}
)
{
"query": {
"param1": ["blah"],
"param2" : ["123", "456"]
}
}
Should we serialize every param value as an array, even if there is only one value? It would make it more explicit what sort of matching is being done, and work better for statically typed languages I'd expect.
from pact-specification.
I think the Map name to Array is the best solution. It will make it easier
to implement in Scala.
The Pact-JVM currently converts it into this structure internally.
On 11 October 2014 10:24, Beth [email protected] wrote:
Having decided that we want to allow flexible ordering of params, except
when the params have the same name, it makes sense for v2 to allow the
params to be specified in a hash in the consumer DSLs, and to be serialised
as a hash in the pact json.some_provider.upon_receiving("a request for something").with(
path: "/something",
query: {
"param1" : like("blah"),
"param2" : [ eg("123", /\d{3}/), eg("456" /\d{3}/ ]
}
){
"query": {
"param1": ["blah"],
"param2" : ["123", "456"]
}}Should we serialize every param value as an array, even if there is only
one value? It would make it more explicit what sort of matching is being
done, and work better for statically typed languages I'd expect.—
Reply to this email directly or view it on GitHub
#2 (comment)
.
from pact-specification.
A map of key -> array of values has been added to V3
from pact-specification.
Going to consider this as closed as v3 is released
https://github.com/pact-foundation/pact-specification/tree/version-3
Feel free to re-open if not
from pact-specification.
Related Issues (20)
- Events driven architecture like aws event bridge contract testing HOT 1
- Feature Request - eachLike(itemDescriptionWithMatchers, exampleArray?) HOT 4
- Definitive word on PACT and HATEOAS HOT 1
- V4 Pact Specification Metadata format changed HOT 3
- Guidance and documentation needed to differentiate between event messages and command messages? HOT 1
- Pending pacts and can-i-deploy HOT 5
- Option to check for no undeclared fields HOT 3
- Generated pact file body include json_class, contents information and doesn't have matchingRules section HOT 2
- V4: Tracking issue for support of synchronous messages HOT 6
- V4: add a boolean matcher
- Matchers don't work with SSE response format HOT 1
- Question: providerStates allowed in any contract? HOT 1
- Type of regular expressions used in pact HOT 2
- How to match xml elements with namespace ? HOT 3
- Serialisation of ProviderStateGenerator HOT 2
- Add number range matcher
- json schema for version 3 pact files HOT 2
- The V4 Specification Retrospectively Alters the V3 Specification for Matchers and Generators HOT 6
- Either matcher in Pact HOT 2
- Convert PACT file to OAS 3.0 file HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pact-specification.