Open richard-reece opened 6 years ago
Pact-JVM provides a number of matchers over what the specification lists. In this case, it looks like the consumer DSL match integer
functions where used. What behaviour would you expect in this case? An error if someone tries to use those matching functions?
The behaviour I would like is that I can verify the contract by tooling other than Pact-JVM (we run a multilingual environment). Currently the non-JVM verifier (implemented to follow the published pact spec, which I believe is reasonable) rejects the contract as invalid.
Either the JVM tooling should be corrected, or the pact spec updated.
Which verifier is rejecting the contract?
The pact V3 spec does list all the extra matchers from the Pact-JVM. It is the V2 version that does not.
How should the Pact-JVM be corrected? It has to support these matchers to be V3 compliant, so the only solution would be to not allow them if you are targeting a V2 spec in your consumer tests.
Please note in the generated contract I pasted in the OP that Pact-JVM is declaring the pact to be against pact spec version 2.0.0 (thus I linked version 2 of the spec). I am not familiar enough with the Pact-JVM contract generation to know how that is generated.
pact-jvm generates contracts with the following assertions:
But "integer" is not a supported matcher (https://github.com/pact-foundation/pact-specification/tree/version-2#supported-matchers)