This repository contains a Python implementation for Pact. Pact is a specification for Consumer Driven Contracts Testing. For further information about Pact project, contracts testing, pros and cons and useful resources please refer to the Pact website.
There are two phases in Consumer Driven Contracts Testing: a Consumer sets up a contract (it's consumer driven after all!), and a Provider honours it. But, before that...
Pact Test is distributed through PyPi so it can be easily included in the
requirements.txt
file or normally installed with pip
:
$ pip install pact-test
Consumers run Provider Tests to create pacts and establish a contract between them and service providers. An example of a Python client using pact test is available at here. Consumers define all the interactions with their providers in the following way:
@service_consumer('PythonEats')
@has_pact_with('PyzzaHut')
class PyzzaHutTest(ServiceProviderTest):
@given('some pizzas exist')
@upon_receiving('a request for a pepperoni pizza')
@with_request({'method': 'get', 'path': '/pizzas/pepperoni/'})
@will_respond_with({'status': 200, 'body': {'id': 42, 'type': 'pepperoni'}})
def test_get_pepperoni_pizza(self):
pizza = get_pizza('pepperoni')
assert pizza['id'] == 42
assert pizza['type'] == 'pepperoni'
This test verifies, against a mock server, the expected interaction and creates
a JSON file (the pact) that will be stored locally and also sent to the
Pact Broker, if available. It is possible to define multiple tests for the same
state in order to verify all the scenarios of interest, For example, we can
test an unhappy 404
situation:
@given('some pizzas exist')
@upon_receiving('a request for an hawaiian pizza')
@with_request({'method': 'get', 'path': '/pizzas/hawaiian/'})
@will_respond_with({'status': 404, 'body': {'message': 'we do not serve pineapple with pizza'}})
def test_get_hawaiian_pizza(self):
pizza = get_pizza('hawaiian')
assert pizza.status_code == 404
assert pizza.json()['message'] == 'we do not serve pineapple with pizza'
Providers run Consumer Tests to verify that they are honouring their pacts with the consumers. There are few examples of an hypothetical restaurant service implemented with the most popular Python web frameworks:
There are few things required to setup and run consumer tests.
This helper class is used by Pact Test to start and stop the web-app before and after the test. It also defines the ports and endpoint to be used by the test. The following is an example of Pact Helper:
class RestaurantPactHelper(PactHelper):
process = None
def setup(self):
self.process = subprocess.Popen('gunicorn start:app -w 3 -b :8080 --log-level error', shell=True)
def tear_down(self):
self.process.kill()
There are few rules for the helper:
- it must extend
PactHelper
class frompact_test
- it must define a
setup
method - it must define a
tear_down
method
It is also possible to override default url (localhost) and port (9999):
class RestaurantPactHelper(PactHelper):
test_url = '0.0.0.0'
test_port = 5000
When a consumer sets a pact, it defines certain states. States are basically pre-requisites to your test. Before honouring the pacts, a provider needs to define such states. For example:
@honours_pact_with('UberEats')
@pact_uri('http://Kalimaha.github.io/src/pacts/pact.json')
class UberEats(ServiceConsumerTest):
@state('some menu items exist')
def test_get_menu_items(self):
DB.save(MenuItem('spam'))
DB.save(MenuItem('eggs'))
In this example, the provider stores some test data in its DB in order to make the system ready to receive mock calls from the consumer and therefore verify the pact.
The default configuration of Pact Test assumes the following values:
- consumer_tests_path:
tests/service_consumers
- provider_tests_path:
tests/service_providers
- pact_broker_uri:
None
It is possible to override such values by creating a file named .pact.json
in the project's root. The following
is an example of a valid configuration file:
{
"consumer_tests_path": "mypath/mytests",
"provider_tests_path": "mypath/mytests",
"pact_broker_uri": "http://example.com/"
}
All fields are optional: only specified fields will override default configuration values.
python3 setup.py install
It is possible to run the tests locally with Docker through the following command:
$ ./bin/test
By default this command tests the library against Python 3.6. It is possible to specify the Python version as follows:
$ ./bin/test <ENV>
Available values for ENV are: py27
, py33
, py34
, py35
py36
, py37
and
py38
. It is also possible to test all the versions at once with:
$ ./bin/test all
$ python3 setup.py sdist upload
With Python Wheels:
$ python3 setup.py sdist bdist_wheel
$ twine upload dist/*