|
1 | 1 | pact-python demo
|
2 | 2 | ================
|
3 | 3 |
|
4 |
| -**NOTE:** This README needs to be updated since adding examples for the pact broker |
5 |
| - |
6 |
| - |
7 | 4 | This simple client/server implementation demos how pact-python can be used for a contract test.
|
8 | 5 |
|
9 | 6 | Further reading about pact is at https://docs.pact.io/ or https://docs.pact.io/blogs-videos-and-articles
|
10 | 7 |
|
11 | 8 | It has 3 components:
|
12 |
| -* `user-app.py` -- a simple flask app that has a REST endpoint for `/users/<name>` which returns a JSON representation of a user |
13 |
| -* `client.py` -- a simple client that gets a user from user-app. |
14 |
| -* `client-test.py` -- a set of test cases using pytest and pact-python to test a simple |
| 9 | +* `pact_python_demo/user-app.py` -- a simple flask app that has a REST endpoint for `/users/<name>` which returns a JSON representation of a user |
| 10 | +* `pact_python_demo/client.py` -- a simple client that gets a user from user-app. |
| 11 | +* `tests/test_client.py` -- a set of test cases using pytest and pact-python to test a simple |
15 | 12 | contract between the client and server.
|
| 13 | +* `broker/` -- contains docker-compose files for a pact broker server |
16 | 14 |
|
17 |
| -Install this with: |
| 15 | +Set up your virtual environment with: |
18 | 16 |
|
19 | 17 | ```
|
20 | 18 | $ pip install pipenv
|
21 | 19 | $ pipenv install
|
22 | 20 | ```
|
23 | 21 |
|
| 22 | +## Creating/validating pacts without the broker |
| 23 | + |
24 | 24 | Enter your venv shell with:
|
25 | 25 | ```
|
26 | 26 | $ pipenv shell
|
27 | 27 | ```
|
28 | 28 |
|
29 | 29 | Run the test with:
|
30 | 30 | ```
|
31 |
| -(venv) $ pytest client-test.py |
| 31 | +(venv) $ pytest |
32 | 32 | ```
|
33 | 33 |
|
34 |
| -You'll see a pact file is generated by this consumer test at `consumer-provider.json` |
| 34 | +You'll see a pact file is generated by this consumer test at `tests/userclientservice-userservice.json` |
35 | 35 |
|
36 | 36 | Then, fire up your server-side app and verify the provider works as expected:
|
37 | 37 | ```
|
38 |
| -(venv) $ python user-app.py |
| 38 | +(venv) $ python pact_python_demo/user-app.py |
39 | 39 | (venv) $ pact-verifier --provider-base-url=http://localhost:5001 \
|
40 |
| - --pact-url=./consumer-provider.json \ |
| 40 | + --pact-url=tests/userclientservice-userservice.json \ |
41 | 41 | --provider-states-setup-url=http://localhost:5001/_pact/provider_states
|
42 | 42 | ```
|
43 | 43 |
|
| 44 | +## Creating/validating pacts and publishing results to the pact broker |
| 45 | +Next, you can try incorporating the pact broker in this process: |
| 46 | + |
| 47 | +Start the broker server: |
| 48 | +``` |
| 49 | +$ cd broker |
| 50 | +$ docker-compose up |
| 51 | +``` |
| 52 | +It's accessible at http://127.0.0.1 with username 'pactbroker' and password 'pactbroker' |
| 53 | + |
| 54 | + |
| 55 | +To run the test, this time pushing the generated pact into the broker with version '0.1' of UserServiceClient, use: |
| 56 | +``` |
| 57 | +(venv) $ pytest --update-pact 0.1 |
| 58 | +``` |
| 59 | + |
| 60 | +The `tests/conftest.py` adds this custom option, and `tests/test_client` has code in the `pact` fixture to upload to the broker if the command line option was passed. |
| 61 | + |
| 62 | + |
| 63 | +Then, you can validate the provider (UserService) and push the result to the broker by running `./verify_pact.sh 0.2` -- which runs the same `pact-verifier` command as above but has additional args for pulling the pact file from the broker (instead of getting the .json locally) and pushing the verification result to the broker. |
| 64 | + |
| 65 | +Log in to the broker and take a look at the matrix. You will see that UserClientService version 0.1 has been verified against UserService version 0.2 |
| 66 | + |
| 67 | + |
44 | 68 | How does this work?
|
45 | 69 | ===================
|
46 | 70 |
|
47 |
| -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. |
| 71 | +The purpose of `test_client.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. |
48 | 72 |
|
49 | 73 | 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`
|
50 | 74 |
|
|
0 commit comments