@klondikemarlen/expect-http-response 1.0.1 → 1.0.2
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.
- package/README.md +44 -7
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -4,7 +4,7 @@ Readable HTTP response failures for Jest and Vitest: focused status errors and c
|
|
|
4
4
|
|
|
5
5
|
## Why This Matcher Exists
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
`toHaveHttpResponse` expresses the response status and complete body as one HTTP contract, with focused diagnostics when that contract fails. Separate status and body assertions provide a useful comparison:
|
|
8
8
|
|
|
9
9
|
```js
|
|
10
10
|
expect(response.status).toEqual(200)
|
|
@@ -19,7 +19,7 @@ expect(response).toEqual(expect.objectContaining({ status: 200, body: expectedBo
|
|
|
19
19
|
|
|
20
20
|
However, a failure against the whole Supertest response can include unrelated headers, request metadata, and raw response text. `toMatchObject` is not an equivalent complete-body replacement: its partial matching can accept unexpected body fields.
|
|
21
21
|
|
|
22
|
-
`toHaveHttpResponse`
|
|
22
|
+
`toHaveHttpResponse` combines the status and body checks while keeping their diagnostics focused:
|
|
23
23
|
|
|
24
24
|
```js
|
|
25
25
|
expect(response).toHaveHttpResponse(200, expectedBody)
|
|
@@ -40,6 +40,43 @@ For example, a changed field among 100 response records remains visible in the d
|
|
|
40
40
|
|
|
41
41
|
This changes the diagnostic boundary, not the equality policy. Complete-body comparison, deliberate asymmetric matches, and the runner's custom equality testers retain their existing meaning.
|
|
42
42
|
|
|
43
|
+
### Example: Whole-Response Failure
|
|
44
|
+
|
|
45
|
+
In a real controller test, the expected title of a returned notice was deliberately changed. On Vitest 4.1.11, the whole-response `toEqual(expect.objectContaining(...))` assertion above produced the following selected diff lines. Domain names and fixture values are anonymized; `...` marks omitted output:
|
|
46
|
+
|
|
47
|
+
```diff
|
|
48
|
+
- "body": {
|
|
49
|
+
- "notices": [
|
|
50
|
+
- ObjectContaining {
|
|
51
|
+
- "id": 1,
|
|
52
|
+
- "title": "Scheduled maintenance",
|
|
53
|
+
...
|
|
54
|
+
+ "header": {
|
|
55
|
+
+ "content-type": "application/json; charset=utf-8",
|
|
56
|
+
...
|
|
57
|
+
+ "req": {
|
|
58
|
+
+ "method": "GET",
|
|
59
|
+
+ "url": "http://127.0.0.1:<port>/notices",
|
|
60
|
+
...
|
|
61
|
+
+ "text": "{\"notices\":[...\"title\":\"Active notice\"...]}",
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
The expected title appears under `body`, but the received title is embedded in escaped response text among unrelated transport details.
|
|
65
|
+
|
|
66
|
+
Using the same expected body with `toHaveHttpResponse` produced these selected lines instead:
|
|
67
|
+
|
|
68
|
+
```diff
|
|
69
|
+
Body mismatch:
|
|
70
|
+
- Expected
|
|
71
|
+
+ Received
|
|
72
|
+
...
|
|
73
|
+
- "title": "Scheduled maintenance",
|
|
74
|
+
...
|
|
75
|
+
+ "title": "Active notice",
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
Both titles are now part of the body comparison, without headers, request metadata, or raw response text. Other body fields can still appear according to the runner's native asymmetric-match formatting.
|
|
79
|
+
|
|
43
80
|
## Installation
|
|
44
81
|
|
|
45
82
|
Install a published release as a development dependency:
|
|
@@ -214,17 +251,17 @@ npm test
|
|
|
214
251
|
npm pack --dry-run
|
|
215
252
|
git switch main
|
|
216
253
|
git pull --ff-only origin main
|
|
217
|
-
git tag v1.0.
|
|
218
|
-
git push origin v1.0.
|
|
219
|
-
gh release create v1.0.
|
|
254
|
+
git tag v1.0.2
|
|
255
|
+
git push origin v1.0.2
|
|
256
|
+
gh release create v1.0.2 --title v1.0.2 --generate-notes
|
|
220
257
|
npm publish --access public
|
|
221
|
-
npm view @klondikemarlen/expect-http-response@1.0.
|
|
258
|
+
npm view @klondikemarlen/expect-http-response@1.0.2 version
|
|
222
259
|
```
|
|
223
260
|
|
|
224
261
|
In a separate consumer project, install the registry artifact:
|
|
225
262
|
|
|
226
263
|
```sh
|
|
227
|
-
npm install --save-dev @klondikemarlen/expect-http-response@1.0.
|
|
264
|
+
npm install --save-dev @klondikemarlen/expect-http-response@1.0.2
|
|
228
265
|
```
|
|
229
266
|
|
|
230
267
|
After publishing, use the actual registry installation in a fresh consumer project and run its matcher and TypeScript registration checks. Do not claim npm availability until the publish and registry install have been observed.
|