matchers

Pact JVM Matchers ================= > Implements matchers for pact requests, responses and messages. This library implements the core matching logic required for matching HTTP requests and responses. It is based on the [V3 pact specification](https://github.com/pact-foundation/pact-specification/tree/version-3) and [V4 pact specification](https://github.com/pact-foundation/pact-specification/tree/version-4). ## Matching request and response parts V3 specification matching is supported for both JSON and XML bodies, headers, query strings and request paths. To understand the basic rules of matching, see [Gotchas](https://docs.pact.io/getting_started/matching/gotchas). For example test cases for matching, see the [Pact Specification Project, version 3](https://github.com/bethesque/pact-specification/tree/version-3). By default, Pact will use string equality matching following Postel's Law. This means that for an actual value to match an expected one, they both must consist of the same sequence of characters. For collections (basically Maps and Lists), they must have the same elements that match in the same sequence, with cases where the additional elements in an actual Map are ignored. Matching rules can be defined for both request and response elements based on a pseudo JSON-Path syntax. ### Matching Bodies For the most part, matching involves matching request and response bodies in JSON or XML format. Other formats will either have their own matching rules, or will follow the JSON one. #### JSON body matching rules Bodies consist of Objects (Maps of Key-Value pairs), Arrays (Lists) and values (Strings, Numbers, true, false, null). Body matching rules are prefixed with `$.`. The following method is used to determine if two bodies match: 1. If both the actual body and expected body are empty, the bodies match. 2. If the actual body is non-empty, and the expected body empty, the bodies match. 3. If the actual body is empty, and the expected body non-empty, the bodies don't match. 4. Otherwise do a comparison on the contents of the bodies. ##### For the body contents comparison: 1. If the actual and expected values are both Objects, compare as Maps. 2. If the actual and expected values are both Arrays, compare as Lists. 3. If the expected value is an Object, and the actual is not, they don't match. 4. If the expected value is an Array, and the actual is not, they don't match. 5. Otherwise, compare the values ##### For comparing Maps 1. If the actual map is non-empty while the expected is empty, they don't match. 2. If we allow unexpected keys, and the number of expected keys is greater than the actual keys, they don't match. 3. If we don't allow unexpected keys, and the expected and actual maps don't have the same number of keys, they don't match. 4. Otherwise, for each expected key and value pair: 1. if the actual map contains the key, compare the values 2. otherwise they don't match Postel's law governs if we allow unexpected keys or not. ##### For comparing lists 1. If there is a body matcher defined that matches the path to the list, default to that matcher and then compare the list contents. 2. If the expected list is empty and the actual one is not, the lists don't match. 3. Otherwise 1. compare the list sizes 2. compare the list contents ###### For comparing list contents 1. For each value in the expected list: 1. If the index of the value is less than the actual list's size, compare the value with the actual value at the same index using the method for comparing values. 2. Otherwise the value doesn't match ##### For comparing values 1. If there is a matcher defined that matches the path to the value, default to that matcher 2. Otherwise compare the values using equality. #### XML body matching rules Bodies consist of a root element, Elements (Lists with children), Attributes (Maps) an