You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit fixes pre-commit linting and formatting issues. To avoid
refactoring all of the existing Python code (which will is going to be
deprecated), the pre-commit configuration has been updated to ignore
these Python files.
All other changes in this commit are purely stylistic.
Signed-off-by: JP-Ellis <josh@jpellis.me>
Copy file name to clipboardexpand all lines: RELEASING.md
+32-38
Original file line number
Diff line number
Diff line change
@@ -2,59 +2,53 @@
2
2
3
3
## Preparing the release
4
4
5
-
The easiest way is to just run the following command from the root folder with
6
-
the HEAD commit on trunk and the appropriate version. We follow
7
-
`<MAJOR>.<MINOR>.<PATCH>` versioning.
5
+
The easiest way is to just run the following command from the root folder with the HEAD commit on trunk and the appropriate version. We follow `<MAJOR>.<MINOR>.<PATCH>` versioning.
8
6
9
-
```shell
10
-
$ script/release_prep.sh X.Y.Z
11
-
```
7
+
```shell
8
+
$ script/release_prep.sh X.Y.Z
9
+
```
12
10
13
11
This script effectively runs the following:
14
12
15
-
1. Increment the version according to semantic versioning rules in `pact/__version__.py`
13
+
1.Increment the version according to semantic versioning rules in `pact/__version__.py`
To upgrade the versions of `pact-mock_service` and `pact-provider-verifier`, change the `PACT_STANDALONE_VERSION`in`setup.py` to match the latest version available from the [pact-ruby-standalone](https://github.com/pact-foundation/pact-ruby-standalone/releases) repository. Do this before preparing the release.
44
43
45
44
## Publishing to pypi
46
45
47
-
1. Wait until GitHub Actions have run and the new tag is available at
1. Wait until GitHub Actions have run and the new tag is available at https://github.com/pact-foundation/pact-python/releases/tag/vX.Y.Z
49
47
50
-
2. Set the title to `pact-python-X.Y.Z`
48
+
2. Set the title to `pact-python-X.Y.Z`
51
49
52
-
3. Save
50
+
3. Save
53
51
54
-
4. Go to GitHub Actions for Pact Python and you should see an 'Upload Python
55
-
Package' action blocked for your version.
52
+
4. Go to GitHub Actions for Pact Python and you should see an 'Upload Python Package' action blocked for your version.
56
53
57
-
5. Click this and then 'Review deployments'. Select 'Upload Python Package'
58
-
and Approve deploy. If you can't do this you may need an administrator to
59
-
give you permissions or do it for you. You should see in Slack #pact-python
60
-
that the release has happened. Verify in [pypi](https://pypi.org/project/pact-python/)
54
+
5. Click this and then'Review deployments'. Select 'Upload Python Package' and Approve deploy. If you can't do this you may need an administrator to give you permissions or do it for you. You should see in Slack #pact-python that the release has happened. Verify in [pypi](https://pypi.org/project/pact-python/)
Copy file name to clipboardexpand all lines: docker/README.md
+7-17
Original file line number
Diff line number
Diff line change
@@ -1,27 +1,20 @@
1
1
# Introduction
2
2
3
-
This is for contributors who want to make changes and test for all different
4
-
versions of python currently supported. If you don't want to set up and install
5
-
all the different python versions locally (and there are some difficulties with
6
-
that) you can just run them in docker using containers.
3
+
This is for contributors who want to make changes and test for all different versions of python currently supported. If you don't want to set up and install all the different python versions locally (and there are some difficulties with that) you can just run them in docker using containers.
7
4
8
5
# Setup
9
6
10
-
To build a container say for Python 3.11, change to the root directory of the
11
-
project and run:
7
+
To build a container say for Python 3.11, change to the root directory of the project and run:
This uses an Alpine based image (currently 3.17), which is available as of
18
-
2023-04 for Python versions 3.7 - 3.11.
13
+
This uses an Alpine based image (currently 3.17), which is available as of 2023-04 for Python versions 3.7 - 3.11.
19
14
20
-
Note: To run tox, the Python version without the '.' is required, i.e. '311'
21
-
instead of '3.11', so some manipulation with `sed` is used to remove the '.'
15
+
Note: To run tox, the Python version without the '.' is required, i.e. '311' instead of '3.11', so some manipulation with `sed` is used to remove the '.'
22
16
23
-
To build for Python versions which require a different Alpine image, such as if
24
-
trying to build against Python 3.6, an extra `ALPINE` arg can be provided:
17
+
To build for Python versions which require a different Alpine image, such as if trying to build against Python 3.6, an extra `ALPINE` arg can be provided:
This directory contains an end-to-end example of using Pact in Python. While
4
-
this document and the documentation within the examples themselves are intended
5
-
to be mostly self-contained, it is highly recommended that you read the [Pact
6
-
Documentation](https://docs.pact.io/) as well.
3
+
This directory contains an end-to-end example of using Pact in Python. While this document and the documentation within the examples themselves are intended to be mostly self-contained, it is highly recommended that you read the [Pact Documentation](https://docs.pact.io/) as well.
7
4
8
-
Assuming you have [hatch](https://hatch.pypa.io/latest/) installed, the example
9
-
suite can be executed with:
5
+
Assuming you have [hatch](https://hatch.pypa.io/latest/) installed, the example suite can be executed with:
10
6
11
7
```sh
12
8
hatch run example
13
9
```
14
10
15
-
The code within the examples is intended to be well documented and you are
16
-
encouraged to look through the code as well (or submit a PR if anything is
17
-
unclear!).
11
+
The code within the examples is intended to be well documented and you are encouraged to look through the code as well (or submit a PR if anything is unclear!).
18
12
19
13
## Overview
20
14
21
-
Pact is a contract testing tool. Contract testing is a way to ensure that
22
-
services (such as an API provider and a client) can communicate with each other.
23
-
This example focuses on HTTP interactions, but Pact can be used to test more
24
-
general interactions as well such as through message queues.
15
+
Pact is a contract testing tool. Contract testing is a way to ensure that services (such as an API provider and a client) can communicate with each other. This example focuses on HTTP interactions, but Pact can be used to test more general interactions as well such as through message queues.
25
16
26
-
An interaction between a HTTP client (the _consumer_) and a server (the
27
-
_provider_) would typically look like this:
17
+
An interaction between a HTTP client (the _consumer_) and a server (the _provider_) would typically look like this:
28
18
29
19
<divalign="center">
30
20
@@ -40,11 +30,7 @@ sequenceDiagram
40
30
41
31
</div>
42
32
43
-
To test this interaction naively would require both the consumer and provider to
44
-
be running at the same time. While this is straightforward in the above example,
45
-
this quickly becomes impractical as the number of interactions grows between
46
-
many microservices. Pact solves this by allowing the consumer and provider to be
47
-
tested independently.
33
+
To test this interaction naively would require both the consumer and provider to be running at the same time. While this is straightforward in the above example, this quickly becomes impractical as the number of interactions grows between many microservices. Pact solves this by allowing the consumer and provider to be tested independently.
48
34
49
35
Pact achieves this be mocking the other side of the interaction:
50
36
@@ -75,34 +61,20 @@ sequenceDiagram
75
61
76
62
</div>
77
63
78
-
In the first stage, the consumer defines a number of interactions in the form
79
-
below. Pact sets up a mock server that will respond to the requests as defined
80
-
by the consumer. All these interactions, containing both the request and
81
-
expected response, are all sent to the Pact Broker.
64
+
In the first stage, the consumer defines a number of interactions in the form below. Pact sets up a mock server that will respond to the requests as defined by the consumer. All these interactions, containing both the request and expected response, are all sent to the Pact Broker.
82
65
83
66
> Given {provider state} \
84
67
> Upon receiving {description} \
85
68
> With {request} \
86
69
> Will respond with {response}
87
70
88
-
In the second stage, the provider retrieves the interactions from the Pact
89
-
Broker. It then sets up a mock client that will make the requests as defined by
90
-
the consumer. Pact then verifies that the responses from the provider match the
91
-
expected responses defined by the consumer.
71
+
In the second stage, the provider retrieves the interactions from the Pact Broker. It then sets up a mock client that will make the requests as defined by the consumer. Pact then verifies that the responses from the provider match the expected responses defined by the consumer.
92
72
93
-
In this way, Pact is consumer driven and can ensure that the provider is
94
-
compatible with the consumer. While this example showcases both sides in Python,
95
-
this is absolutely not required. The provider could be written in any language,
96
-
and satisfy contracts from a number of consumers all written in different
97
-
languages.
73
+
In this way, Pact is consumer driven and can ensure that the provider is compatible with the consumer. While this example showcases both sides in Python, this is absolutely not required. The provider could be written in any language, and satisfy contracts from a number of consumers all written in different languages.
98
74
99
75
### Consumer
100
76
101
-
The consumer in this example is a simple Python script that makes a HTTP GET
102
-
request to a server. It is defined in [`src/consumer.py`](src/consumer.py). The
103
-
tests for the consumer are defined in
104
-
[`tests/test_00_consumer.py`](tests/test_00_consumer.py). Each interaction is
105
-
defined using the format mentioned above. Programmatically, this looks like:
77
+
The consumer in this example is a simple Python script that makes a HTTP GET request to a server. It is defined in [`src/consumer.py`](src/consumer.py). The tests for the consumer are defined in [`tests/test_00_consumer.py`](tests/test_00_consumer.py). Each interaction is defined using the format mentioned above. Programmatically, this looks like:
106
78
107
79
```py
108
80
expected: dict[str, Any] = {
@@ -121,17 +93,9 @@ expected: dict[str, Any] = {
121
93
122
94
### Provider
123
95
124
-
This example showcases to different providers, one written in Flask and one
125
-
written in FastAPI. Both are simple Python web servers that respond to a HTTP
126
-
GET request. The Flask provider is defined in [`src/flask.py`](src/flask.py) and
127
-
the FastAPI provider is defined in [`src/fastapi.py`](src/fastapi.py). The
128
-
tests for the providers are defined in
129
-
[`tests/test_01_provider_flask.py`](tests/test_01_provider_flask.py) and
This example showcases to different providers, one written in Flask and one written in FastAPI. Both are simple Python web servers that respond to a HTTP GET request. The Flask provider is defined in [`src/flask.py`](src/flask.py) and the FastAPI provider is defined in [`src/fastapi.py`](src/fastapi.py). The tests for the providers are defined in [`tests/test_01_provider_flask.py`](tests/test_01_provider_flask.py) and [`tests/test_01_provider_fastapi.py`](tests/test_01_provider_fastapi.py).
131
97
132
-
Unlike the consumer side, the provider side is responsible to responding to the
133
-
interactions defined by the consumers. In this regard, the provider testing
134
-
is rather simple:
98
+
Unlike the consumer side, the provider side is responsible to responding to the interactions defined by the consumers. In this regard, the provider testing is rather simple:
The complication comes from the fact that the provider needs to know what state
146
-
to be in before responding to the request. In order to achieve this, a testing
147
-
endpoint is defined that sets the state of the provider as defined in the
148
-
`provider_states_setup_url` above. For example, the consumer requests has _Given
149
-
user 123 exists_ as the provider state, and the provider will need to ensure
150
-
that this state is satisfied. This would typically entail setting up a database
151
-
with the correct data, but it is advisable to achieve the equivalent state by
152
-
mocking the appropriate calls. This has been showcased in both provider
153
-
examples.
109
+
The complication comes from the fact that the provider needs to know what state to be in before responding to the request. In order to achieve this, a testing endpoint is defined that sets the state of the provider as defined in the `provider_states_setup_url` above. For example, the consumer requests has _Given user 123 exists_ as the provider state, and the provider will need to ensure that this state is satisfied. This would typically entail setting up a database with the correct data, but it is advisable to achieve the equivalent state by mocking the appropriate calls. This has been showcased in both provider examples.
154
110
155
111
### Broker
156
112
157
-
The broker acts as the intermediary between these test suites. It stores the
158
-
interactions defined by the consumer and makes them available to the provider.
159
-
Once the provider has verified that it satisfies all interactions, the broker
160
-
also stores the verification results. The example here runs the open source
161
-
broker within a Docker container. An alternative is to use the hosted [Pactflow
162
-
service](https://pactflow.io).
113
+
The broker acts as the intermediary between these test suites. It stores the interactions defined by the consumer and makes them available to the provider. Once the provider has verified that it satisfies all interactions, the broker also stores the verification results. The example here runs the open source broker within a Docker container. An alternative is to use the hosted [Pactflow service](https://pactflow.io).
0 commit comments