{ "info": { "author": "ReeceTech", "author_email": "richard.jones@reece.com.au", "bugtrack_url": null, "classifiers": [ "Intended Audience :: Developers", "License :: OSI Approved :: MIT License", "Programming Language :: Python :: 3", "Programming Language :: Python :: 3.6", "Topic :: Software Development :: Testing", "Topic :: Software Development :: Testing :: Acceptance", "Topic :: Software Development :: Testing :: Mocking" ], "description": "# pactman\n\n[![](https://img.shields.io/pypi/v/pactman.svg)](https://pypi.org/project/pactman/)\n\nPython version of Pact mocking, generation and verification.\n\nEnables [consumer driven contract testing], providing unit test mocking of provider services\nand DSL for the consumer project, and interaction playback and verification for the service\nprovider project. Currently supports versions 1.1, 2 and 3 of the [Pact specification].\n\nFor more information about what Pact is, and how it can help you\ntest your code more efficiently, check out the [Pact documentation].\n\nContains code originally from the [pact-python](https://github.com/pact-foundation/pact-python) project.\n\npactman is maintained by the [ReeceTech](https://www.reecetech.com.au/) team as part of their toolkit to\nkeep their large (and growing) microservices architecture under control.\n\n## pactman vs pact-python\n\nThe key difference is all functionality is implemented in Python, rather than shelling out or forking\nto the ruby implementation. This allows for a much nicer mocking user experience (it mocks urllib3\ndirectly), is faster, less messy configuration (multiple providers means multiple ruby processes spawned\non different ports).\n\nWhere `pact-python` required management of a background Ruby server, and manually starting and stopping\nit, `pactman` allows a much nicer usage like:\n\n```python\nimport requests\nfrom pactman import Consumer, Provider\n\npact = Consumer('Consumer').has_pact_with(Provider('Provider'))\n\ndef test_interaction():\n pact.given(\"some data exists\").upon_receiving(\"a request\") \\\n .with_request(\"get\", \"/\", query={\"foo\": [\"bar\"]}).will_respond_with(200)\n with pact:\n requests.get(pact.uri, params={\"foo\": [\"bar\"]})\n```\n\nIt also supports a broader set of the pact specification (versions 1.1 through to 3).\n\nThe pact verifier has been engineered from the start to talk to a pact broker (both to discover pacts\nand to return verification results).\n\nThere\u2019s a few other quality of life improvements, but those are the big ones.\n\n# How to use pactman\n\n## Installation\n\n`pactman` requires Python 3.6 to run.\n\n```\npip install pactman\n```\n\n## Writing a Pact\nCreating a complete contract is a two step process:\n\n1. Create a test on the consumer side that declares the expectations it has of the provider\n2. Create a provider state that allows the contract to pass when replayed against the provider\n\n## Writing the Consumer Test\n\nIf we have a method that communicates with one of our external services, which we'll call\n`Provider`, and our product, `Consumer` is hitting an endpoint on `Provider` at\n`/users/` to get information about a particular user.\n\nIf the code to fetch a user looked like this:\n\n```python\nimport requests\n\ndef get_user(user_name):\n response = requests.get(f'http://service.example/users/{user_name}')\n return response.json()\n```\n\nThen `Consumer`'s contract test might look something like this:\n\n```python\nimport unittest\nfrom pactman import Consumer, Provider\n\npact = Consumer('Consumer').has_pact_with(Provider('Provider'))\n\nclass GetUserInfoContract(unittest.TestCase):\n def test_get_user(self):\n expected = {\n 'username': 'UserA',\n 'id': 123,\n 'groups': ['Editors']\n }\n\n pact.given(\n 'UserA exists and is not an administrator'\n ).upon_receiving(\n 'a request for UserA'\n ).with_request(\n 'GET', '/users/UserA'\n ) .will_respond_with(200, body=expected)\n\n with pact:\n result = get_user('UserA')\n\n self.assertEqual(result, expected)\n```\n\nThis does a few important things:\n\n - Defines the Consumer and Provider objects that describe our product and our service under test\n - Uses `given` to define the setup criteria for the Provider `UserA exists and is not an administrator`\n - Defines what the request that is expected to be made by the consumer will contain\n - Defines how the server is expected to respond\n\nUsing the Pact object as a [context manager], we call our method under test\nwhich will then communicate with the Pact mock. The mock will respond with\nthe items we defined, allowing us to assert that the method processed the response and\nreturned the expected value.\n\nIf you want more control over when the mock is configured and the interactions verified,\nuse the `setup` and `verify` methods, respectively:\n\n```python\nConsumer('Consumer').has_pact_with(Provider('Provider')).given(\n 'UserA exists and is not an administrator'\n).upon_receiving(\n 'a request for UserA'\n).with_request(\n 'GET', '/users/UserA'\n) .will_respond_with(200, body=expected)\n\npact.setup()\ntry:\n # Some additional steps before running the code under test\n result = get_user('UserA')\n # Some additional steps before verifying all interactions have occurred\nfinally:\n pact.verify()\n```\n\n### An important note about pact relationship definition\n\nYou may have noticed that the pact relationship is defined at the module level in our\nexamples:\n\n```python\npact = Consumer('Consumer').has_pact_with(Provider('Provider'))\n```\n\nThis is because it *must only be done once* per test suite. By default the pact file is\ncleared out when that relationship is defined, so if you define it more than once per test\nsuite you'll end up only storing the *last* pact declared per relationship. For more on this\nsubject, see [writing multiple pacts](#writing-multiple-pacts).\n\n### Requests\n\nWhen defining the expected HTTP request that your code is expected to make you\ncan specify the method, path, body, headers, and query:\n\n```python\npact.with_request(\n method='GET',\n path='/api/v1/my-resources/',\n query={'search': 'example'}\n)\n```\n\n`query` is used to specify URL query parameters, so the above example expects\na request made to `/api/v1/my-resources/?search=example`.\n\n```python\npact.with_request(\n method='POST',\n path='/api/v1/my-resources/123',\n body={'user_ids': [1, 2, 3]},\n headers={'Content-Type': 'application/json'},\n)\n```\n\nYou can define exact values for your expected request like the examples above,\nor you can use the matchers defined later to assist in handling values that are\nvariable.\n\n### Some important has_pact_with() options()\n\nThe `has_pact_with(provider...)` call has quite a few options documented in its API, but a couple are\nworth mentioning in particular:\n\n`version` declares the pact specification version that the provider supports. This defaults to \"2.0.0\", but \"3.0.0\"\nis also acceptable if your provider supports [Pact specification version 3]:\n\n```python\nfrom pactman import Consumer, Provider\npact = Consumer('Consumer').has_pact_with(Provider('Provider'), version='3.0.0')\n```\n\n`file_write_mode` defaults to `\"overwrite\"` and should be that or `\"merge\"`. Overwrite ensures\nthat any existing pact file will be removed when `has_pact_with()` is invoked. Merge will retain\nthe pact file and add new pacts to that file. See [writing multiple pacts](#writing-multiple-pacts).\nIf you absolutely do not want pact files to be written, use `\"never\"`. \n\n`use_mocking_server` defaults to `False` and controls the mocking method used by `pactman`. The default is to\npatch `urllib3`, which is the library underpinning `requests` and is also used by some other projects. If you\nare using a different library to make your HTTP requests which does not use `urllib3` underneath then you will need\nto set the `use_mocking_server` argument to `True`. This causes `pactman` to run an actual HTTP server to mock the\nrequests (the server is listening on `pact.uri` - use that to redirect your HTTP requests to the mock server.) You\nmay also set the `PACT_USE_MOCKING_SERVER` environment variable to \"yes\" to force your entire suite to use the server\napproach. You should declare the pact particpants (consumer and provider) outside of your tests and will need\nto start and stop the mocking service outside of your tests too. The code below shows what using the server might\nlook like:\n\n```python\nimport atexit\nfrom pactman import Consumer, Provider\npact = Consumer('Consumer').has_pact_with(Provider('Provider'), use_mocking_server=True)\npact.start_mocking()\natexit.register(pact.stop_mocking)\n``````\n\nYou'd then use `pact` to declare pacts between those participants.\n\n### Writing multiple pacts\n\nDuring a test run you're likely to need to write multiple pact interactions for a consumer/provider\nrelationship. `pactman` will manage the pact file as follows:\n\n- When `has_pact_with()` is invoked it will by default remove any existing pact JSON file for the\n stated consumer & provider.\n- You may invoke `Consumer('Consumer').has_pact_with(Provider('Provider'))` once at the start of\n your tests. This could be done as a pytest module or session fixture, or through some other\n mechanism and store it in a variable. By convention this is called `pact` in all of our examples.\n- If that is not suitable, you may manually indicate to `has_pact_with()` that it should either\n retain (`file_write_mode=\"merge\"`) or remove (`file_write_mode=\"overwrite\"`) the existing\n pact file.\n\n### Some words about given()\n\nYou use `given()` to indicate to the provider that they should have some state in order to\nbe able to satisfy the interaction. You should agree upon the state and its specification\nin discussion with the provider.\n\nIf you are defining a version 3 pact you may define provider states more richly, for example:\n\n```python\n(pact\n .given(\"this is a simple state as in v2\")\n .and_given(\"also the user must exist\", username=\"alex\")\n)\n```\n\nNow you may specify additional parameters to accompany your provider state text. These are\npassed as keyword arguments, and they're optional. You may also provider additional provider\nstates using the `and_given()` call, which may be invoked many times if necessary. It and\n`given()` have the same calling convention: a provider state name and any optional parameters.\n\n## Expecting Variable Content\nThe default validity testing of equal values works great if that user information is always\nstatic, but what happens if the user has a last updated field that is set to the current time\nevery time the object is modified? To handle variable data and make your tests more robust,\nthere are several helpful matchers:\n\n### Includes(matcher, sample_data)\n\n*Available in version 3.0.0+ pacts*\n\nAsserts that the value should contain the given substring, for example::\n\n```python\nfrom pactman import Includes, Like\nLike({\n 'id': 123, # match integer, value varies\n 'content': Includes('spam', 'Sample spamming content') # content must contain the string \"spam\"\n})\n```\n\nThe `matcher` and `sample_data` are used differently by consumer and provider depending\nupon whether they're used in the `with_request()` or `will_respond_with()` sections\nof the pact. Using the above example:\n\n#### Includes in request\nWhen you run the tests for the consumer, the mock will verify that the data\nthe consumer uses in its request contains the `matcher` string, raising an AssertionError\nif invalid. When the contract is verified by the provider, the `sample_data` will be\nused in the request to the real provider service, in this case `'Sample spamming content'`.\n\n#### Includes in response\nWhen you run the tests for the consumer, the mock will return the data you provided\nas `sample_data`, in this case `'Sample spamming content'`. When the contract is verified on the\nprovider, the data returned from the real provider service will be verified to ensure it\ncontains the `matcher` string.\n\n### Term(matcher, sample_data)\nAsserts the value should match the given regular expression. You could use this\nto expect a timestamp with a particular format in the request or response where\nyou know you need a particular format, but are unconcerned about the exact date:\n\n```python\nfrom pactman import Term\n\n(pact\n .given('UserA exists and is not an administrator')\n .upon_receiving('a request for UserA')\n .with_request(\n 'post',\n '/users/UserA/info',\n body={'commencement_date': Term('\\d+-\\d+-\\d', '1972-01-01')})\n .will_respond_with(200, body={\n 'username': 'UserA',\n 'last_modified': Term('\\d+-\\d+-\\d+T\\d+:\\d+:\\d+', '2016-12-15T20:16:01')\n }))\n```\n\nThe `matcher` and `sample_data` are used differently by consumer and provider depending\nupon whether they're used in the `with_request()` or `will_respond_with()` sections\nof the pact. Using the above example:\n\n#### Term in request\nWhen you run the tests for the consumer, the mock will verify that the `commencement_date`\nthe consumer uses in its request matches the `matcher`, raising an AssertionError\nif invalid. When the contract is verified by the provider, the `sample_data` will be\nused in the request to the real provider service, in this case `1972-01-01`.\n\n#### Term in response\nWhen you run the tests for the consumer, the mock will return the `last_modified` you provided\nas `sample_data`, in this case `2016-12-15T20:16:01`. When the contract is verified on the\nprovider, the regex will be used to search the response from the real provider service\nand the test will be considered successful if the regex finds a match in the response.\n\n### Like(sample_data)\nAsserts the element's type matches the `sample_data`. For example:\n\n```python\nfrom pactman import Like\nLike(123) # Matches if the value is an integer\nLike('hello world') # Matches if the value is a string\nLike(3.14) # Matches if the value is a float\n```\n\n#### Like in request\nWhen you run the tests for the consumer, the mock will verify that values are\nof the correct type, raising an AssertionError if invalid. When the contract is\nverified by the provider, the `sample_data` will be used in the request to the\nreal provider service.\n\n#### Like in response\nWhen you run the tests for the consumer, the mock will return the `sample_data`.\nWhen the contract is verified on the provider, the values generated by the provider\nservice will be checked to match the type of `sample_data`.\n\n#### Applying Like to complex data structures\nWhen a dictionary is used as an argument for Like, all the child objects (and their child objects etc.)\nwill be matched according to their types, unless you use a more specific matcher like a Term.\n\n```python\nfrom pactman import Like, Term\nLike({\n 'username': Term('[a-zA-Z]+', 'username'),\n 'id': 123, # integer\n 'confirmed': False, # boolean\n 'address': { # dictionary\n 'street': '200 Bourke St' # string\n }\n})\n```\n\n### EachLike(sample_data, minimum=1)\nAsserts the value is an array type that consists of elements\nlike `sample_data`. It can be used to assert simple arrays:\n\n```python\nfrom pactman import EachLike\nEachLike(1) # All items are integers\nEachLike('hello') # All items are strings\n```\n\nOr other matchers can be nested inside to assert more complex objects:\n\n```python\nfrom pactman import EachLike, Term\nEachLike({\n 'username': Term('[a-zA-Z]+', 'username'),\n 'id': 123,\n 'groups': EachLike('administrators')\n})\n```\n\n> Note, you do not need to specify everything that will be returned from the Provider in a\n> JSON response, any extra data that is received will be ignored and the tests will still pass.\n\nFor more information see [Matching](https://docs.pact.io/documentation/matching.html)\n\n### Enforcing equality matching with Equals\n\n*Available in version 3.0.0+ pacts*\n\nIf you have a sub-term of a `Like` which needs to match an exact value like the default\nvalidity test then you can use `Equals`, for example::\n\n```python\nfrom pactman import Equals, Like\nLike({\n 'id': 123, # match integer, value varies\n 'username': Equals('alex') # username must always be \"alex\"\n})\n```\n\n### Body payload rules\nThe `body` payload is assumed to be JSON data. In the absence of a `Content-Type` header\nwe assume `Content-Type: application/json; charset=UTF-8` (JSON text is Unicode and the\ndefault encoding is UTF-8).\n\nDuring verification non-JSON payloads are compared for equality.\n\nDuring mocking, the HTTP response will be handled as:\n\n1. If there's no `Content-Type` header, assume JSON: serialise with `json.dumps()`, encode to\n UTF-8 and add the header `Content-Type: application/json; charset=UTF-8`.\n2. If there's a `Content-Type` header and it says `application/json` then serialise with\n json.dumps() and use the charset in the header, defaulting to UTF-8.\n3. Otherwise pass through the `Content-Type` header and body as-is.\n Binary data is not supported.\n\n\n## Verifying Pacts Against a Service\nYou have two options for verifying pacts against a service you created:\n\n1. Use the `pactman-verifier` command-line program which replays the pact assertions against\n a running instance of your service, or\n2. Use the `pytest` support built into pactman to replay the pacts as test cases, allowing\n use of other testing mechanisms such as mocking and transaction control.\n\n### Using `pactman-verifier`\n\nRun `pactman-verifier -h` to see the options available. To run all pacts registered to a provider in a [Pact Broker]:\n\n pactman-verifier -b http://pact-broker.example/ \n\nYou can pass in a local pact file with `-l`, this will verify the service against the local file instead of the broker:\n\n pactman-verifier -l /tmp/localpact.json \n\nYou can use `--custom-provider-header` to pass in headers to be passed to provider state setup and verify calls. it can \nbe used multiple times\n\n pactman-verifier -b --custom-provider-header \"someheader:value\" --custom-provider-header \n \"this:that\" \n \nAn additional header may also be supplied in the `PROVIDER_EXTRA_HEADER` environment variable, though the command\nline argument(s) would override this.\n\n#### Provider States\n\nIn many cases, your contracts will need very specific data to exist on the provider\nto pass successfully. If you are fetching a user profile, that user needs to exist,\nif querying a list of records, one or more records needs to exist. To support\ndecoupling the testing of the consumer and provider, Pact offers the idea of provider\nstates to communicate from the consumer what data should exist on the provider.\n\nWhen setting up the testing of a provider you will also need to setup the management of\nthese provider states. The Pact verifier does this by making additional HTTP requests to\nthe `` you provide. This URL could be\non the provider application or a separate one. Some strategies for managing state include:\n\n- Having endpoints in your application that are not active in production that create and delete your datastore state\n- A separate application that has access to the same datastore to create and delete,\n like a separate App Engine module or Docker container pointing to the same datastore\n- A standalone application that can start and stop the other server with different datastore states\n\nFor more information about provider states, refer to the [Pact documentation] on [Provider States].\n\n### Verifying Pacts Using `pytest`\n\nTo verify pacts for a provider you would write a new pytest test module in the provider's test suite.\nIf you don't want it to be exercised in your usual unit test run you can call it `verify_pacts.py`.\n\nYour test code needs to use the `pact_verifier` fixture provided by pactman, invoking\nits `verify()` method with the URL to the running instance of your service (`pytest-django` provides\na handy `live_server` fixture which works well here) and a callback to set up provider states (described\nbelow).\n\nYou'll need to include some extra command-line arguments to pytest (also described below) to indicate\nwhere the pacts should come from, and whether verification results should be posted to a pact broker.\n\nAn example for a Django project might contain:\n\n```python\nfrom django.contrib.auth.models import User\nfrom pactman.verifier.verify import ProviderStateMissing\n\ndef provider_state(name, **params):\n if name == 'the user \"pat\" exists':\n User.objects.create(username='pat', fullname=params['fullname'])\n else:\n raise ProviderStateMissing(name)\n\ndef test_pacts(live_server, pact_verifier):\n pact_verifier.verify(live_server.url, provider_state)\n```\n\nThe test function may do any level of mocking and data setup using standard pytest fixtures - so mocking\ndownstream APIs or other interactions within the provider may be done with standard monkeypatching.\n\n#### Provider states using `pytest`\n\nThe `provider_state` function passed to `pact_verifier.verify` will be passed the `providerState` and\n`providerStates` for all pacts being verified.\n\n- For pacts with **providerState** the `name` argument will be the `providerState` value,\n and `params` will be empty.\n- For pacts with **providerStates** the function will be invoked once per entry in `providerStates`\n array with the `name` argument taken from the array entry `name` parameter, and `params` from\n the `params` parameter. \n\n#### Command line options to control `pytest` verifying pacts\n\nOnce you have written the pytest code, you need to invoke pytest with additional arguments:\n\n`--pact-broker-url=` provides the base URL of the Pact broker to retrieve pacts from for the\nprovider. You must also provide `--pact-provider-name=` to identify which provider to\nretrieve pacts for from the broker. You may provider `--pact-verify-consumer=` to limit\nthe pacts verified to just that consumer. As with the command-line verifier, you may provide basic\nauth details in the broker URL, or through the `PACT_BROKER_AUTH` environment variable. If your broker\nrequires a bearer token you may provide it with `--pact-broker-token=` or the `PACT_BROKER_TOKEN`\nenvironment variable.\n\n`--pact-files=` verifies some on-disk pact JSON files identified by the wildcard pattern\n(unix glob pattern matching).\n\nIf you pulled the pacts from a broker and wish to publish verification results, use `--pact-publish-results`\nto turn on publishing the results. This option also requires you to specify `--pact-provider-version=`.\n\nSo, for example:\n\n```bash\n# verify some local pacts in /tmp/pacts\n$ pytest --pact-files=/tmp/pacts/*.json tests/verify_pacts.py\n\n# verify some pacts in a broker for the provider MyService\n$ pytest --pact-broker-url=http://pact-broker.example/ --pact-provider-name=MyService tests/verify_pacts.py\n```\n\nIf you need to see the traceback that caused a pact failure you can use the verbosity flag\nto pytest (`pytest -v`).\n\nSee the \"pact\" section in the pytest command-line help (`pytest -h`) for all command-line options.\n\n### Pact Broker Configuration\n\nYou may also specify the broker URL in the environment variable `PACT_BROKER_URL`.\n\nIf HTTP Basic Auth is required for the broker, that may be provided in the URL:\n \n pactman-verifier -b http://user:password@pact-broker.example/ ...\n pytest --pact-broker-url=http://user:password@pact-broker.example/ ...\n\nor set in the `PACT_BROKER_AUTH` environment variable as `user:password`.\n\nIf your broker needs a bearer token then you may provide that on the command line or set it in the\nenvironment variable `PACT_BROKER_TOKEN`.\n\n#### Filtering Broker Pacts by Tag\n\nIf your consumer pacts have tags (called \"consumer version tags\" because they attach to specific\nversions) then you may specify the tag(s) to fetch pacts for on the command line. Multiple tags\nmay be specified, and all pacts matching any tags specified will be verified. For example, to ensure\nyou're verifying your Provider against the *production* pact versions from your Consumers, use:\n\n pactman-verifier --consumer-version-tag=production -b http://pact-broker.example/ ...\n pytest --pact-verify-consumer-tag=production --pact-broker-url=http://pact-broker.example/ ...\n\n\n# Development\nPlease read [CONTRIBUTING.md](CONTRIBUTING.md)\n\nTo setup a development environment:\n\n1. Clone the repository `https://github.com/reecetech/pactman` and invoke `git submodule update --init`\n2. Install Python 3.6 from source or using a tool like [pyenv]\n3. Its recommended to create a Python [virtualenv] for the project\n\nTo run tests, use:\n`tox`\n\nTo package the application, run:\n`python setup.py sdist`\n\nThis creates a `dist/pactman-N.N.N.tar.gz` file, where the Ns are the current version.\nFrom there you can use pip to install it:\n`pip install ./dist/pactman-N.N.N.tar.gz`\n\n## Release History\n\n3.0.0 (FUTURE, DEPRECATION WARNINGS)\n\n- remove DEPRECATED `--pact-consumer-name` command-line option\n\n2.25.0\n\n- Add option to allow pytest to succeed even if a pact verification fails\n\n2.24.0\n\n- Better integration of pact failure information in pytest\n\n2.23.0\n\n- Enable setting of authentication credentials when connecting to the pact broker\n- Allow filtering of pacts fetched from broker to be filtered by consumer version tag\n- Improve the naming and organisation of the pytest command line options\n\n2.22.0\n\n- Better implementation of change in 2.21.0\n\n2.21.0\n\n- Handle warning level messages in command line output handler\n\n2.20.0\n\n- Fix pytest mode to correctly detect array element rule failure as a pytest failure\n- Allow restricting pytest verification runs to a single consumer using --pact-consumer-name\n\n2.19.0\n\n- Correct teardown of pact context manager where the pact is used in multiple\n interactions (`with interaction1, interaction2` instead of `with pact`).\n\n2.18.0\n\n- Correct bug in cleanup that resulted in urllib mocking breaking.\n\n2.17.0\n\n- Handle absence of any provider state (!) in pytest setup.\n\n2.16.0\n\n- Delay shenanigans around checking pacts directory until pacts are actually written\n to allow module-level pact definition without side effects.\n\n2.15.0\n\n- Fix structure of serialisation for header matching rules.\n- Add `\"never\"` to the `file_write_mode` options.\n- Handle x-www-form-urlencoded POST request bodies.\n\n2.14.0\n\n- Improve verbose messages to clarify what they're saying.\n\n2.13.0\n\n- Add ability to supply additional headers to provider during verification (thanks @ryallsa)\n\n2.12.1\n\n- Fix pact-python Term compatibility\n\n2.12.0\n\n- Add `Equals` and `Includes` matchers for pact v3+\n- Make verification fail if missing header specified in interaction\n- Significantly improved support for pytest provider verification of pacts\n- Turned pact state call failures into warnings rather than errors\n\n2.11.0\n\n- Ensure query param values are lists\n\n2.10.0\n\n- Allow `has_pact_with()` to accept `file_write_mode`\n- Fix bug introduced in 2.9.0 where generating multiple pacts would result in a single pact\n being recorded\n\n2.9.0\n\n- Fix `with_request` when called with a dict query (thanks Cong)\n- Make `start_mocking()` and `stop_mocking()` optional with non-server mocking\n- Add shortcut so `python -m pactman.verifier.command_line` is just `python -m pactman`\n (mostly used in testing before release)\n- Handle the `None` provider state\n- Ensure pact spec versions are consistent across all mocks used to generate a pact file\n\n2.8.0\n\n- Close up some edge cases in body content during mocking, and document in README\n\n2.7.0\n\n- Added `and_given()` as a method of defining additonal provider states for v3+ pacts\n- Added more tests for pact generation (serialisation) which fixed a few edge case bugs\n- Fix handling of lower-case HTTP methods in verifier (thanks Cong!)\n\n2.6.1\n\n- Fix issue where mocked `urlopen` didn't handle the correct number of positional arguments\n\n2.6.0\n\n- Fix several issues cause by a failure to detect failure in several test cases\n (header, path and array element rules may not have been applied)\n- Fix rules applying to a single non-first element in an array\n- Fix generation of consumer / provider name in