pytest-httpchain 0.1.0__tar.gz → 0.1.2__tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,11 +1,11 @@
1
1
  Metadata-Version: 2.4
2
2
  Name: pytest-httpchain
3
- Version: 0.1.0
3
+ Version: 0.1.2
4
4
  Summary: pytest plugin for HTTP testing using JSON files
5
5
  Keywords: testing,pytest,requests
6
6
  Author: Alexander Eresov
7
7
  Author-email: Alexander Eresov <aeresov@gmail.com>
8
- License-File: LICENSE
8
+ License-Expression: MIT
9
9
  Classifier: Development Status :: 5 - Production/Stable
10
10
  Classifier: Framework :: Pytest
11
11
  Classifier: Intended Audience :: Developers
@@ -33,7 +33,7 @@ A pytest plugin for testing HTTP endpoints.
33
33
 
34
34
  ## Overview
35
35
 
36
- `pytest-httpchain` is an integration testing framework for HTTP APIs based on battle-hardened [requests](https://requests.readthedocs.io) lib.\
36
+ `pytest-httpchain` is an integration testing framework for HTTP APIs based on battle-hardened [requests](https://requests.readthedocs.io) lib.
37
37
  It aims at helping with common HTTP API testing scenarios, where user needs to make several calls in specific order using data obtained along the way, like auth tokens or resource ids.
38
38
 
39
39
  ## Installation
@@ -60,26 +60,26 @@ The following optional dependencies are available:
60
60
 
61
61
  ### Pytest integration
62
62
 
63
- Most of pytest magic can be used: markers, fixtures, other plugins.\
63
+ Most of pytest magic can be used: markers, fixtures, other plugins.
64
64
 
65
65
  > NOTE: parametrization is not yet implemented, therefore `parametrize` marker won't have any effect.
66
66
 
67
67
  ### Declarative format
68
68
 
69
- Test scenarios are written declaratively in JSON files.\
70
- `pytest-httpchain` supports JSONRef, so use can reuse arbitrary parts of your scenarios with `$ref` directive.\
69
+ Test scenarios are written declaratively in JSON files.
70
+ `pytest-httpchain` supports JSONRef, so use can reuse arbitrary parts of your scenarios with `$ref` directive.
71
71
  Properties are merged in a greedy way with type checking.
72
72
 
73
73
  ### Multi-stage tests
74
74
 
75
- Each test scenario contains 1+ stages; each stage is a single HTTP call.\
75
+ Each test scenario contains 1+ stages; each stage is a single HTTP call.
76
76
  `pytest-httpchain` executes stages in the order they are listed in scenario file; one stage failure stops the execution chain.
77
77
 
78
78
  ### Common data context and variable substitution
79
79
 
80
- `pytest-httpchain` maintains key-value data storage throughout the execution.\
81
- This storage ("common data context") is populated with declared variables, fixtures and data saved by stages. The data remains there throughout the scenario execution.\
82
- Writing scenarios, you can use Jinja-style expressions like `"{{ var }}"` for JSON values. `pytest-httpchain` does variable substitution dynamically right before executing a stage, and uses common data context keys as variables in these expressions.\
80
+ `pytest-httpchain` maintains key-value data storage throughout the execution.
81
+ This storage ("common data context") is populated with declared variables, fixtures and data saved by stages. The data remains there throughout the scenario execution.
82
+ Writing scenarios, you can use Jinja-style expressions like `"{{ var }}"` for JSON values. `pytest-httpchain` does variable substitution dynamically right before executing a stage, and uses common data context keys as variables in these expressions.
83
83
  Values from common data context also might be verified during verified/asserted.
84
84
 
85
85
  ### User functions
@@ -176,28 +176,28 @@ def now_utc():
176
176
  Scenario we created:
177
177
 
178
178
  - common data context is seeded with the first variable `user_id`
179
- - **get_user**\
180
- url is assembled using `user_id` variable from common data context\
181
- HTTP GET call is made\
182
- we verify the call returned code 200\
179
+ - **get_user**
180
+ url is assembled using `user_id` variable from common data context
181
+ HTTP GET call is made
182
+ we verify the call returned code 200
183
183
  assuming JSON body is returned, we extract a value by JMESPath expression `user.name` and save it to common data context under `user_name` key
184
- - **update_user**\
185
- `now_utc` fixture value is injected into common data context\
186
- url is assembled using `user_id` variable from common data context\
187
- we create JSON body in place using values from common data context, note that `now_utc` is converted to string in place\
188
- HTTP PUT call with body is made\
189
- we verify the call returned code 200\
190
- - **cleanup**\
191
- finalizing call meant for graceful exit\
184
+ - **update_user**
185
+ `now_utc` fixture value is injected into common data context
186
+ url is assembled using `user_id` variable from common data context
187
+ we create JSON body in place using values from common data context, note that `now_utc` is converted to string in place
188
+ HTTP PUT call with body is made
189
+ we verify the call returned code 200
190
+ - **cleanup**
191
+ finalizing call meant for graceful exit
192
192
  `always_run` parameter means this stage will be executed regardless of errors in previous stages
193
193
 
194
194
  For detailed examples see [USAGE.md](USAGE.md).
195
195
 
196
196
  ## Configuration
197
197
 
198
- - Test file discovery is based on this name pattern: `test_<name>.<suffix>.json`.\
198
+ - Test file discovery is based on this name pattern: `test_<name>.<suffix>.json`.
199
199
  The `suffix` is configurable as pytest ini option, default value is **http**.
200
- - `$ref` instructions can point to other files; absolute and relative paths are supported.\
200
+ - `$ref` instructions can point to other files; absolute and relative paths are supported.
201
201
  You can limit the depth of relative path traversal using `ref_parent_traversal_depth` ini option, default value is **3**.
202
202
 
203
203
  ## MCP Server
@@ -206,7 +206,7 @@ For detailed examples see [USAGE.md](USAGE.md).
206
206
 
207
207
  ### Installation
208
208
 
209
- The optional dependency `mcp` installs MCP server's package and `pytest-httpchain-mcp` script.\
209
+ The optional dependency `mcp` installs MCP server's package and `pytest-httpchain-mcp` script.
210
210
  Use this script as call target for your MCP configuration.
211
211
 
212
212
  Claude Code `.mcp.json` example:
@@ -8,7 +8,7 @@ A pytest plugin for testing HTTP endpoints.
8
8
 
9
9
  ## Overview
10
10
 
11
- `pytest-httpchain` is an integration testing framework for HTTP APIs based on battle-hardened [requests](https://requests.readthedocs.io) lib.\
11
+ `pytest-httpchain` is an integration testing framework for HTTP APIs based on battle-hardened [requests](https://requests.readthedocs.io) lib.
12
12
  It aims at helping with common HTTP API testing scenarios, where user needs to make several calls in specific order using data obtained along the way, like auth tokens or resource ids.
13
13
 
14
14
  ## Installation
@@ -35,26 +35,26 @@ The following optional dependencies are available:
35
35
 
36
36
  ### Pytest integration
37
37
 
38
- Most of pytest magic can be used: markers, fixtures, other plugins.\
38
+ Most of pytest magic can be used: markers, fixtures, other plugins.
39
39
 
40
40
  > NOTE: parametrization is not yet implemented, therefore `parametrize` marker won't have any effect.
41
41
 
42
42
  ### Declarative format
43
43
 
44
- Test scenarios are written declaratively in JSON files.\
45
- `pytest-httpchain` supports JSONRef, so use can reuse arbitrary parts of your scenarios with `$ref` directive.\
44
+ Test scenarios are written declaratively in JSON files.
45
+ `pytest-httpchain` supports JSONRef, so use can reuse arbitrary parts of your scenarios with `$ref` directive.
46
46
  Properties are merged in a greedy way with type checking.
47
47
 
48
48
  ### Multi-stage tests
49
49
 
50
- Each test scenario contains 1+ stages; each stage is a single HTTP call.\
50
+ Each test scenario contains 1+ stages; each stage is a single HTTP call.
51
51
  `pytest-httpchain` executes stages in the order they are listed in scenario file; one stage failure stops the execution chain.
52
52
 
53
53
  ### Common data context and variable substitution
54
54
 
55
- `pytest-httpchain` maintains key-value data storage throughout the execution.\
56
- This storage ("common data context") is populated with declared variables, fixtures and data saved by stages. The data remains there throughout the scenario execution.\
57
- Writing scenarios, you can use Jinja-style expressions like `"{{ var }}"` for JSON values. `pytest-httpchain` does variable substitution dynamically right before executing a stage, and uses common data context keys as variables in these expressions.\
55
+ `pytest-httpchain` maintains key-value data storage throughout the execution.
56
+ This storage ("common data context") is populated with declared variables, fixtures and data saved by stages. The data remains there throughout the scenario execution.
57
+ Writing scenarios, you can use Jinja-style expressions like `"{{ var }}"` for JSON values. `pytest-httpchain` does variable substitution dynamically right before executing a stage, and uses common data context keys as variables in these expressions.
58
58
  Values from common data context also might be verified during verified/asserted.
59
59
 
60
60
  ### User functions
@@ -151,28 +151,28 @@ def now_utc():
151
151
  Scenario we created:
152
152
 
153
153
  - common data context is seeded with the first variable `user_id`
154
- - **get_user**\
155
- url is assembled using `user_id` variable from common data context\
156
- HTTP GET call is made\
157
- we verify the call returned code 200\
154
+ - **get_user**
155
+ url is assembled using `user_id` variable from common data context
156
+ HTTP GET call is made
157
+ we verify the call returned code 200
158
158
  assuming JSON body is returned, we extract a value by JMESPath expression `user.name` and save it to common data context under `user_name` key
159
- - **update_user**\
160
- `now_utc` fixture value is injected into common data context\
161
- url is assembled using `user_id` variable from common data context\
162
- we create JSON body in place using values from common data context, note that `now_utc` is converted to string in place\
163
- HTTP PUT call with body is made\
164
- we verify the call returned code 200\
165
- - **cleanup**\
166
- finalizing call meant for graceful exit\
159
+ - **update_user**
160
+ `now_utc` fixture value is injected into common data context
161
+ url is assembled using `user_id` variable from common data context
162
+ we create JSON body in place using values from common data context, note that `now_utc` is converted to string in place
163
+ HTTP PUT call with body is made
164
+ we verify the call returned code 200
165
+ - **cleanup**
166
+ finalizing call meant for graceful exit
167
167
  `always_run` parameter means this stage will be executed regardless of errors in previous stages
168
168
 
169
169
  For detailed examples see [USAGE.md](USAGE.md).
170
170
 
171
171
  ## Configuration
172
172
 
173
- - Test file discovery is based on this name pattern: `test_<name>.<suffix>.json`.\
173
+ - Test file discovery is based on this name pattern: `test_<name>.<suffix>.json`.
174
174
  The `suffix` is configurable as pytest ini option, default value is **http**.
175
- - `$ref` instructions can point to other files; absolute and relative paths are supported.\
175
+ - `$ref` instructions can point to other files; absolute and relative paths are supported.
176
176
  You can limit the depth of relative path traversal using `ref_parent_traversal_depth` ini option, default value is **3**.
177
177
 
178
178
  ## MCP Server
@@ -181,7 +181,7 @@ For detailed examples see [USAGE.md](USAGE.md).
181
181
 
182
182
  ### Installation
183
183
 
184
- The optional dependency `mcp` installs MCP server's package and `pytest-httpchain-mcp` script.\
184
+ The optional dependency `mcp` installs MCP server's package and `pytest-httpchain-mcp` script.
185
185
  Use this script as call target for your MCP configuration.
186
186
 
187
187
  Claude Code `.mcp.json` example:
@@ -1,6 +1,6 @@
1
1
  [project]
2
2
  name = "pytest-httpchain"
3
- version = "0.1.0"
3
+ version = "0.1.2"
4
4
  description = "pytest plugin for HTTP testing using JSON files"
5
5
  readme = "README.md"
6
6
  requires-python = ">=3.13,<4.0"
@@ -13,7 +13,7 @@ dependencies = [
13
13
  "rich>=13.7.0",
14
14
  ]
15
15
  keywords = ["testing", "pytest", "requests"]
16
- license-files = ["LICENSE"]
16
+ license = "MIT"
17
17
  classifiers = [
18
18
  "Development Status :: 5 - Production/Stable",
19
19
  "Framework :: Pytest",
@@ -1,21 +0,0 @@
1
- MIT License
2
-
3
- Copyright (c) 2025 aeresov
4
-
5
- Permission is hereby granted, free of charge, to any person obtaining a copy
6
- of this software and associated documentation files (the "Software"), to deal
7
- in the Software without restriction, including without limitation the rights
8
- to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9
- copies of the Software, and to permit persons to whom the Software is
10
- furnished to do so, subject to the following conditions:
11
-
12
- The above copyright notice and this permission notice shall be included in all
13
- copies or substantial portions of the Software.
14
-
15
- THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16
- IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17
- FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18
- AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19
- LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20
- OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21
- SOFTWARE.