Pact V4 RFC
uglyog opened this issue · comments
This is the tracking issue for creating a Pact V4 format. This will include both changes to the Pact file format as well as how the behaviour would change (i.e matchers).
The process would be to create individual changes as separate issues (so that different conversations don't make following this one difficult) tagged as V4 and linked to this one. When those issues are approved though community consensus, we can then add then to a markdown file detailing the change and then update the contents of the V4 branch.
Current V4 proposals:
[RELEASED(Rust, Pact-JS V3, Pact-JVM)] Checking a list contains a particular item #38
[RELEASED(Rust, Pact-JVM)] Matching the values in a map ignoring the keys #47
[RELEASED(Rust, Pact-JVM)] Message Pact refactor #56 #70
[RELEASED(Rust)] add an optional comments to the interaction #45
[REMOVED] store contract details for the consumer and provider #34
[RELEASED(Rust, Pact-JVM)] combine message and rest interactions in the same file #79
[RELEASED(Rust)] support synchronous messages #86
[REMOVED] support user supplied matchers and generators
[RELEASED(Rust, Pact-JVM)] Support user specified identifier for interactions #72
[RELEASED(Rust)] Loose checking of HTTP status range #68
[RELEASED(Rust, Pact-JVM)] Flag to indicate the body has been stored in an encoded form (i.e. base64) #80
[RELEASED(Rust)] Interaction level pending status, set by the consumer team? #73
[REMOVED] Matching rules for sub-path expressions #74
[RELEASED(Rust, Pact-JVM)] Matching arrays ignoring the order #77
[RELEASED(Rust, Pact-JVM)] Add tags to individual interactions #75
[RELEASED(Rust, Pact-JVM)] Add boolean matcher #87
I'd like to add: #72
I'd like to table 3 significant changes, or things to consider in our next version:
- Support an expanded set of interaction modes (see image below for use cases and modes)
- Support a way to encode different payloads (e.g. Avro, Protobufs, GraphQL). This may be an embedded thing, or externalised schema. We may want to consider how we could work better with OpenAPI specs as part of this
- Support new transports (gRPC and http/2 for example)
These will expand into lower level tasks/proposals, but we ought to formalise how we think about it more generally before we go too specific.
EDIT: Created a ticket for 2 #76
Some constructive feedback. The documentation could do with a spruce up, which I know Tim Jones is well aware of. Quite often we are forced to search elsewhere online for documentation which doesn't work as it's out of date and no longer applies. Some 'real world' data in the example code would be nice (I'm specifically referring to pact-jvm and pact-workshop-jvm). Usually simple data types like strings are used whereas an example or two of an object or two (nothing too complex, eg. a Person with name, age, address would suffice) would help greatly as there's usually a subtle difference (which can take ages to track down) in testing scenarios with these. All in all though, love Pact and suggest it on all new projects. Great support too!
I'd like to add #68 - loose checking of HTTP status codes. Needs some careful thinking around the use cases- but I think it could be a powerful feature if we design it nicely.
Interaction level pending status, set by the consumer team? #73
Matching rules for sub-path expressions #74
I've added some more thoughts on external schemas and provider driven contracts in #76. They may need to be separated, but hopefully it's a good starting point for a conversation.
Added #77
Added #79
I'd like to add support for extending Pact via plugins: #83
Removing support user supplied matchers and generators as that is what the plugins could provide
I'm adding #87
Closing this as the V4 is no longer WIP