Assumptions based on experience with pacts so for:
- The most common type of matching that is useful is asserting that:
- The expected keys are present
- The values at the actual keys are of the same class (string/number/nil) as the expected values
- Occasionally we'll want a literal match
- Occasionally we'll want a regular expresssion
- Extra keys in a hash are OK for responses but not for requests (following the "be strict with what you send out, be lax with what you accept" principle)
- Extra items in an array are debatable (extra keys in a hash are generally ignored, however, all items in an array are generally processed, so allowing "unverified" extras to sneak in could be a bad thing. Working out what to do with "extras" is not immediately obvious to me however.)
Related thoughts:
- Literal matching (the current default) has made our tests brittle, and makes it much longer to set up the test data for pact:verify
- Whatever form of serialization is used, it should be language non-specific (currently, regular expressions are implemented in a ruby specific way)
- When a regular expression is used, both an example value and a regular expression matcher are used, however, they are never both used at the same time. In a request, the example value is used in the request that is replayed against the provider, however, the regular expression is used in determining whether a request "matches" an expected interaction on the mock server. In a response, the regular expression is used in pact:verify, and the example value is returned by the mock server. I believe there is value in serialising both the example value and the regular expression to the pact file, as the JSON requests and responses are of great value in documenting an interaction.
The belief that it is useful to serialize both example and regex has influenced my design, as has the belief that there is value in keeping the example separate from the matching information so that it is more easily read and understood as a form of documentation (eg. not embedding matching info inside the response body)
** Given that there is generated markdown documentation now, how important is it to keep the response and request bodies human readable?
** Backwards compatiblity is one reason to keep the matching data separate from the request/response bodies.