Closed StefH closed 2 years ago
Hi @StefH! I don't believe a JSON schema exists for them, no.
The recommendation is to serialise a v2 pact for now (we also support use of v3 for this feature so you could also do that).
Most of the features in v3 and v4 of Pact are not going to be use to this use case - such as Matchers and Generators - because they can't be inferred by the examples.
@mefellows I've created a PR which enables WireMock.Net to save the internal mappings to the Pact V2 json format.
In the future this code will be updated when needed.
Maybe you can take a look at the PR.
This is Awesome!! One thing I noticed is that the JSON serialisation is different to the spec: https://github.com/WireMock-Net/WireMock.Net/pull/748/files#diff-bd3932495781a219fda99eb55b250d4f0ce81b829887c94f311e5d68b2c106c6
(UpperCamelCase instead of lowerCamelCase). I haven't tested, but if it's producing a pact file this way it's possible it will cause issues.
I also note that you are capturing Matching Rules. Strictly speaking, for this use case they aren't necessary, but I am interested to know the scenarios in which you will be able to reliably generate one.
@mefellows Thank you reviewing the PR.
:one: lowerCamelCase --> I'll fix this in next release
:two: Matching Rules Can you give a specific example on this?
2️⃣ Matching Rules Can you give a specific example on this?
Matching rules are used by Pact during provider verification testing, to make tests less brittle (see https://docs.pact.io/getting_started/matching). They allow you to say "I want this shape object to be returned, but I don't care if the value is different. Just check that the keys exist and the value matches a type/regex/etc.".
The issue arises during replay, where Pact sends a request per interaction to the actual provider and then checks the response. If exact values are used, then minor data changes will result in a failure, even though what the consumer really cares about is the type.
The primary use case for this generator feature, is for use with Pactflow's bi-directional contract testing feature, which ignores matching rules because it checks the examples in the consumer contract (what this feature produces) and the implicit (or explicit) JSON schema in the provider OAS.
That is, it's always flexible by default.
Now, it's possible people would want to use this generator for the standard Pact workflow. If that's the case, then without matching rules this form of testing would be very painful for the above reasons (brittle provider tests).
If you can generate matching rules, my question then is how do you do that? It's worth documenting the two use cases and advising against the standard Pact process, if matching rules aren't serialised.
@mefellows
When I follow your documentation on https://bitbucket.org/atlassian/pact-json-schema/src/master/schemas/v2/schema.json it seems that there is only version 1 and 2 available.
But when I look at this page: https://github.com/pact-foundation/pact-specification
There is also version 3 and 4 available?