mirror of
https://github.com/wiremock/WireMock.Net.git
synced 2026-01-11 14:20:29 +01:00
Integrate with Pact #412
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @StefH on GitHub (Mar 28, 2022).
Originally assigned to: @StefH on GitHub.
@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?
@mefellows commented on GitHub (Mar 28, 2022):
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.
@StefH commented on GitHub (Apr 22, 2022):
@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.
https://github.com/WireMock-Net/WireMock.Net/pull/748
@mefellows commented on GitHub (May 10, 2022):
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.
@StefH commented on GitHub (May 10, 2022):
@mefellows
Thank you reviewing the PR.
1️⃣ lowerCamelCase --> I'll fix this in next release
2️⃣ Matching Rules
Can you give a specific example on this?
@mefellows commented on GitHub (May 12, 2022):
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.