Initial commit

Author: bsquizz

.gitignore

@@ -0,0 +1,8 @@
+*.json
+log/*
+reports/*
+tmp/*
+*.pyc
+*.log
+.cache/*
+.pytest_cache/*

Pipfile

@@ -0,0 +1,30 @@
+[[source]]
+url = "https://pypi.org/simple"
+verify_ssl = true
+name = "pypi"
+
+[dev-packages]
+
+[packages]
+atomicwrites = "*"
+attrs = "*"
+certifi = "*"
+chardet = "*"
+click = "*"
+idna = "*"
+more-itertools = "*"
+pact-python = "*"
+pipenv = "*"
+pluggy = "*"
+psutil = "*"
+py = "*"
+pytest = "*"
+requests = "*"
+six = "*"
+"urllib3" = "*"
+virtualenv = "*"
+virtualenv-clone = "*"
+flask = "*"
+
+[requires]
+python_version = "2.7"

Pipfile.lock

@@ -0,0 +1,62 @@
+pact-python demo
+================
+
+This simple client/server implementation demos how pact-python can be used for a contract test.
+
+Further reading about pact is at https://docs.pact.io/ or https://docs.pact.io/blogs-videos-and-articles
+
+It has 3 components:
+* `user-app.py` -- a simple flask app that has a REST endpoint for `/users/<name>` which returns a JSON representation of a user
+* `client.py` -- a simple client that gets a user from user-app.
+* `client-test.py` -- a set of test cases using pytest and pact-python to test a simple
+contract between the client and server.
+
+Install this with:
+
+```
+$ pip install pipenv
+$ pipenv install
+```
+
+Enter your venv shell with:
+```
+$ pipenv shell
+```
+
+Run the test with:
+```
+(venv) $ pytest client-test.py
+```
+
+You'll see a pact file is generated by this consumer test at `consumer-provider.json`
+
+Then, fire up your server-side app and verify the provider works as expected:
+```
+(venv) $ python user-app.py
+(venv) $ pact-verifier --provider-base-url=http://localhost:5001 \
+            --pact-url=./consumer-provider.json \
+            --provider-states-setup-url=http://localhost:5001/_pact/provider_states
+```
+
+How does this work?
+===================
+
+The purpose of `client-test.py` is to simply verify that **if the server sends me what I'm expecting, MY client code behaves properly**. It is essentially a unit test to exercise your client code using a mocked server. Except in this case, the mock server is now a "pact mock provider". In the test, you have configured the mock provider server to respond to your client with certain data. This is the mock data to represent how you'd expect the provider to behave **given the proper state exists on the provider.** Using that mock data, you verify your client-side code works.
+
+Two tests were created to verify that my client behaves properly if: a) I get a 200OK response back w/ the json I'd expect to see, or b) I get a 404 back and I should be returning `None`
+
+For example, `client` expects that if `UserA` exists and it sends a GET to `/users/UserA`, it will get back JSON about UserA that has a name, uuid, timestamp for when the user was created, and a boolean indicating if the users is an admin or not. If the server responds with a 404, user client should return `None`.
+
+When your tests pass, a json **pact file** is generated. The `user-app` team can then take this pact file, and use it to verify that their service responds to requests in the way your client expects.
+
+## Provider states
+
+A key part of this is **provider states**:
+* `client.py` expects a 200OK response with json about 'UserA' **given that userA exists on the provider**
+* In order for pact to verify the provider, `user-app.py` has to implement ways of **setting up the needed state**. This is done via a `provider-setup-url` which may reside on the provider app itself, or it could reside somewhere else (for example, some other test service you have setup that lives outside your provider app to populate your backend DB)
+* In this demo, the user app has provided another REST endpoint at `/_pact/provider_states` which the `pact-verifier` will send POST requests to. Depending on the state the pact-verifier asks for, the provider will need to set itself up (e.g. make DB changes, or do other things) to get itself into "the right state" before the verifier sends the "request under test" to it.
+
+## Isn't my server gonna send back different stuff?
+Yes. The real server may respond with a timestamp or uuid that does not necessarily look like the mock values you created in your tests. Therefore, the `Term` object is used to say that **the server could send me anything that looks like this regex and that would be good for me, but for the purpose of this test I am using \<this fake value\>**.
+
+The generated pact file used to verify the provider will only say "you need to be sending me data that looks like this regex" for timestamp and id. But, my client is not going to let server return with `name=UserB` if it asked for `name=UserA`, so the pact file is essentially saying "given that User A exists, and I send you a GET for userA, `name` in the JSON should be UserA"

README.md

@@ -0,0 +1,67 @@
+import atexit
+import os
+import unittest
+
+from pact import Consumer, Like, Provider, Term
+import pytest
+
+from .client import UserClient
+
+PACT_MOCK_HOST = 'localhost'
+PACT_MOCK_PORT = 1234
+
+
+@pytest.fixture
+def client():
+    return UserClient(
+        'http://{host}:{port}'
+        .format(host=PACT_MOCK_HOST, port=PACT_MOCK_PORT)
+    )
+
+
+@pytest.fixture(scope='module')
+def pact():
+    pact = Consumer('Consumer').has_pact_with(
+        Provider('Provider'), host_name=pact_mock_host, port=pact_mock_port)
+    pact.start_service()
+    atexit.register(pact.stop_service)
+    return pact
+
+
+def test_get_user_non_admin(pact, client):
+    expected = {
+        'name': 'UserA',
+        'id': Term(
+            r'^[a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89ab][a-f0-9]{3}-?[a-f0-9]{12}\Z',
+            '00000000-0000-4000-a000-000000000000'
+        ),
+        'created_on': Term(
+            r'\d+-\d+-\d+T\d+:\d+:\d+',
+            '2016-12-15T20:16:01'
+        ),
+        'admin': False
+    }
+
+    (pact
+     .given('UserA exists and is not an administrator')
+     .upon_receiving('a request for UserA')
+     .with_request('get', '/users/UserA')
+     .will_respond_with(200, body=Like(expected)))
+
+    with pact:
+        result = client.get_user('UserA')
+
+    # assert something with the result, for ex, did I process 'result' properly?
+    # or was I able to deserialize correctly? etc.
+
+def test_get_non_existing_user(pact, client):
+    (pact
+     .given('UserA does not exist')
+     .upon_receiving('a request for UserA')
+     .with_request('get', '/users/UserA')
+     .will_respond_with(404))
+
+    with pact:
+        result = client.get_user('UserA')
+
+    assert result is None