@nage-api/testing 1.0.0-beta.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/LICENSE +202 -0
- package/README.md +259 -0
- package/dist/assertions/envelope.d.ts +43 -0
- package/dist/assertions/envelope.js +116 -0
- package/dist/containers/harness.d.ts +123 -0
- package/dist/containers/harness.js +222 -0
- package/dist/doubles/index.d.ts +100 -0
- package/dist/doubles/index.js +201 -0
- package/dist/fixtures/builders.d.ts +74 -0
- package/dist/fixtures/builders.js +179 -0
- package/dist/fixtures/deterministic.d.ts +52 -0
- package/dist/fixtures/deterministic.js +95 -0
- package/dist/index.d.ts +32 -0
- package/dist/index.js +83 -0
- package/dist/packs/authz-bypass.pack.d.ts +53 -0
- package/dist/packs/authz-bypass.pack.js +162 -0
- package/dist/packs/error-non-leakage.pack.d.ts +48 -0
- package/dist/packs/error-non-leakage.pack.js +81 -0
- package/dist/packs/no-leak.d.ts +55 -0
- package/dist/packs/no-leak.js +151 -0
- package/dist/packs/query-allow-list.pack.d.ts +36 -0
- package/dist/packs/query-allow-list.pack.js +90 -0
- package/dist/packs/upload-validation.pack.d.ts +46 -0
- package/dist/packs/upload-validation.pack.js +0 -0
- package/dist/test-api.d.ts +64 -0
- package/dist/test-api.js +15 -0
- package/package.json +45 -0
package/LICENSE
ADDED
|
@@ -0,0 +1,202 @@
|
|
|
1
|
+
|
|
2
|
+
Apache License
|
|
3
|
+
Version 2.0, January 2004
|
|
4
|
+
http://www.apache.org/licenses/
|
|
5
|
+
|
|
6
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
7
|
+
|
|
8
|
+
1. Definitions.
|
|
9
|
+
|
|
10
|
+
"License" shall mean the terms and conditions for use, reproduction,
|
|
11
|
+
and distribution as defined by Sections 1 through 9 of this document.
|
|
12
|
+
|
|
13
|
+
"Licensor" shall mean the copyright owner or entity authorized by
|
|
14
|
+
the copyright owner that is granting the License.
|
|
15
|
+
|
|
16
|
+
"Legal Entity" shall mean the union of the acting entity and all
|
|
17
|
+
other entities that control, are controlled by, or are under common
|
|
18
|
+
control with that entity. For the purposes of this definition,
|
|
19
|
+
"control" means (i) the power, direct or indirect, to cause the
|
|
20
|
+
direction or management of such entity, whether by contract or
|
|
21
|
+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
|
22
|
+
outstanding shares, or (iii) beneficial ownership of such entity.
|
|
23
|
+
|
|
24
|
+
"You" (or "Your") shall mean an individual or Legal Entity
|
|
25
|
+
exercising permissions granted by this License.
|
|
26
|
+
|
|
27
|
+
"Source" form shall mean the preferred form for making modifications,
|
|
28
|
+
including but not limited to software source code, documentation
|
|
29
|
+
source, and configuration files.
|
|
30
|
+
|
|
31
|
+
"Object" form shall mean any form resulting from mechanical
|
|
32
|
+
transformation or translation of a Source form, including but
|
|
33
|
+
not limited to compiled object code, generated documentation,
|
|
34
|
+
and conversions to other media types.
|
|
35
|
+
|
|
36
|
+
"Work" shall mean the work of authorship, whether in Source or
|
|
37
|
+
Object form, made available under the License, as indicated by a
|
|
38
|
+
copyright notice that is included in or attached to the work
|
|
39
|
+
(an example is provided in the Appendix below).
|
|
40
|
+
|
|
41
|
+
"Derivative Works" shall mean any work, whether in Source or Object
|
|
42
|
+
form, that is based on (or derived from) the Work and for which the
|
|
43
|
+
editorial revisions, annotations, elaborations, or other modifications
|
|
44
|
+
represent, as a whole, an original work of authorship. For the purposes
|
|
45
|
+
of this License, Derivative Works shall not include works that remain
|
|
46
|
+
separable from, or merely link (or bind by name) to the interfaces of,
|
|
47
|
+
the Work and Derivative Works thereof.
|
|
48
|
+
|
|
49
|
+
"Contribution" shall mean any work of authorship, including
|
|
50
|
+
the original version of the Work and any modifications or additions
|
|
51
|
+
to that Work or Derivative Works thereof, that is intentionally
|
|
52
|
+
submitted to Licensor for inclusion in the Work by the copyright owner
|
|
53
|
+
or by an individual or Legal Entity authorized to submit on behalf of
|
|
54
|
+
the copyright owner. For the purposes of this definition, "submitted"
|
|
55
|
+
means any form of electronic, verbal, or written communication sent
|
|
56
|
+
to the Licensor or its representatives, including but not limited to
|
|
57
|
+
communication on electronic mailing lists, source code control systems,
|
|
58
|
+
and issue tracking systems that are managed by, or on behalf of, the
|
|
59
|
+
Licensor for the purpose of discussing and improving the Work, but
|
|
60
|
+
excluding communication that is conspicuously marked or otherwise
|
|
61
|
+
designated in writing by the copyright owner as "Not a Contribution."
|
|
62
|
+
|
|
63
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity
|
|
64
|
+
on behalf of whom a Contribution has been received by Licensor and
|
|
65
|
+
subsequently incorporated within the Work.
|
|
66
|
+
|
|
67
|
+
2. Grant of Copyright License. Subject to the terms and conditions of
|
|
68
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
69
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
70
|
+
copyright license to reproduce, prepare Derivative Works of,
|
|
71
|
+
publicly display, publicly perform, sublicense, and distribute the
|
|
72
|
+
Work and such Derivative Works in Source or Object form.
|
|
73
|
+
|
|
74
|
+
3. Grant of Patent License. Subject to the terms and conditions of
|
|
75
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
76
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
77
|
+
(except as stated in this section) patent license to make, have made,
|
|
78
|
+
use, offer to sell, sell, import, and otherwise transfer the Work,
|
|
79
|
+
where such license applies only to those patent claims licensable
|
|
80
|
+
by such Contributor that are necessarily infringed by their
|
|
81
|
+
Contribution(s) alone or by combination of their Contribution(s)
|
|
82
|
+
with the Work to which such Contribution(s) was submitted. If You
|
|
83
|
+
institute patent litigation against any entity (including a
|
|
84
|
+
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
|
85
|
+
or a Contribution incorporated within the Work constitutes direct
|
|
86
|
+
or contributory patent infringement, then any patent licenses
|
|
87
|
+
granted to You under this License for that Work shall terminate
|
|
88
|
+
as of the date such litigation is filed.
|
|
89
|
+
|
|
90
|
+
4. Redistribution. You may reproduce and distribute copies of the
|
|
91
|
+
Work or Derivative Works thereof in any medium, with or without
|
|
92
|
+
modifications, and in Source or Object form, provided that You
|
|
93
|
+
meet the following conditions:
|
|
94
|
+
|
|
95
|
+
(a) You must give any other recipients of the Work or
|
|
96
|
+
Derivative Works a copy of this License; and
|
|
97
|
+
|
|
98
|
+
(b) You must cause any modified files to carry prominent notices
|
|
99
|
+
stating that You changed the files; and
|
|
100
|
+
|
|
101
|
+
(c) You must retain, in the Source form of any Derivative Works
|
|
102
|
+
that You distribute, all copyright, patent, trademark, and
|
|
103
|
+
attribution notices from the Source form of the Work,
|
|
104
|
+
excluding those notices that do not pertain to any part of
|
|
105
|
+
the Derivative Works; and
|
|
106
|
+
|
|
107
|
+
(d) If the Work includes a "NOTICE" text file as part of its
|
|
108
|
+
distribution, then any Derivative Works that You distribute must
|
|
109
|
+
include a readable copy of the attribution notices contained
|
|
110
|
+
within such NOTICE file, excluding those notices that do not
|
|
111
|
+
pertain to any part of the Derivative Works, in at least one
|
|
112
|
+
of the following places: within a NOTICE text file distributed
|
|
113
|
+
as part of the Derivative Works; within the Source form or
|
|
114
|
+
documentation, if provided along with the Derivative Works; or,
|
|
115
|
+
within a display generated by the Derivative Works, if and
|
|
116
|
+
wherever such third-party notices normally appear. The contents
|
|
117
|
+
of the NOTICE file are for informational purposes only and
|
|
118
|
+
do not modify the License. You may add Your own attribution
|
|
119
|
+
notices within Derivative Works that You distribute, alongside
|
|
120
|
+
or as an addendum to the NOTICE text from the Work, provided
|
|
121
|
+
that such additional attribution notices cannot be construed
|
|
122
|
+
as modifying the License.
|
|
123
|
+
|
|
124
|
+
You may add Your own copyright statement to Your modifications and
|
|
125
|
+
may provide additional or different license terms and conditions
|
|
126
|
+
for use, reproduction, or distribution of Your modifications, or
|
|
127
|
+
for any such Derivative Works as a whole, provided Your use,
|
|
128
|
+
reproduction, and distribution of the Work otherwise complies with
|
|
129
|
+
the conditions stated in this License.
|
|
130
|
+
|
|
131
|
+
5. Submission of Contributions. Unless You explicitly state otherwise,
|
|
132
|
+
any Contribution intentionally submitted for inclusion in the Work
|
|
133
|
+
by You to the Licensor shall be under the terms and conditions of
|
|
134
|
+
this License, without any additional terms or conditions.
|
|
135
|
+
Notwithstanding the above, nothing herein shall supersede or modify
|
|
136
|
+
the terms of any separate license agreement you may have executed
|
|
137
|
+
with Licensor regarding such Contributions.
|
|
138
|
+
|
|
139
|
+
6. Trademarks. This License does not grant permission to use the trade
|
|
140
|
+
names, trademarks, service marks, or product names of the Licensor,
|
|
141
|
+
except as required for reasonable and customary use in describing the
|
|
142
|
+
origin of the Work and reproducing the content of the NOTICE file.
|
|
143
|
+
|
|
144
|
+
7. Disclaimer of Warranty. Unless required by applicable law or
|
|
145
|
+
agreed to in writing, Licensor provides the Work (and each
|
|
146
|
+
Contributor provides its Contributions) on an "AS IS" BASIS,
|
|
147
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
148
|
+
implied, including, without limitation, any warranties or conditions
|
|
149
|
+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
|
150
|
+
PARTICULAR PURPOSE. You are solely responsible for determining the
|
|
151
|
+
appropriateness of using or redistributing the Work and assume any
|
|
152
|
+
risks associated with Your exercise of permissions under this License.
|
|
153
|
+
|
|
154
|
+
8. Limitation of Liability. In no event and under no legal theory,
|
|
155
|
+
whether in tort (including negligence), contract, or otherwise,
|
|
156
|
+
unless required by applicable law (such as deliberate and grossly
|
|
157
|
+
negligent acts) or agreed to in writing, shall any Contributor be
|
|
158
|
+
liable to You for damages, including any direct, indirect, special,
|
|
159
|
+
incidental, or consequential damages of any character arising as a
|
|
160
|
+
result of this License or out of the use or inability to use the
|
|
161
|
+
Work (including but not limited to damages for loss of goodwill,
|
|
162
|
+
work stoppage, computer failure or malfunction, or any and all
|
|
163
|
+
other commercial damages or losses), even if such Contributor
|
|
164
|
+
has been advised of the possibility of such damages.
|
|
165
|
+
|
|
166
|
+
9. Accepting Warranty or Additional Liability. While redistributing
|
|
167
|
+
the Work or Derivative Works thereof, You may choose to offer,
|
|
168
|
+
and charge a fee for, acceptance of support, warranty, indemnity,
|
|
169
|
+
or other liability obligations and/or rights consistent with this
|
|
170
|
+
License. However, in accepting such obligations, You may act only
|
|
171
|
+
on Your own behalf and on Your sole responsibility, not on behalf
|
|
172
|
+
of any other Contributor, and only if You agree to indemnify,
|
|
173
|
+
defend, and hold each Contributor harmless for any liability
|
|
174
|
+
incurred by, or claims asserted against, such Contributor by reason
|
|
175
|
+
of your accepting any such warranty or additional liability.
|
|
176
|
+
|
|
177
|
+
END OF TERMS AND CONDITIONS
|
|
178
|
+
|
|
179
|
+
APPENDIX: How to apply the Apache License to your work.
|
|
180
|
+
|
|
181
|
+
To apply the Apache License to your work, attach the following
|
|
182
|
+
boilerplate notice, with the fields enclosed by brackets "[]"
|
|
183
|
+
replaced with your own identifying information. (Don't include
|
|
184
|
+
the brackets!) The text should be enclosed in the appropriate
|
|
185
|
+
comment syntax for the file format. We also recommend that a
|
|
186
|
+
file or class name and description of purpose be included on the
|
|
187
|
+
same "printed page" as the copyright notice for easier
|
|
188
|
+
identification within third-party archives.
|
|
189
|
+
|
|
190
|
+
Copyright [yyyy] [name of copyright owner]
|
|
191
|
+
|
|
192
|
+
Licensed under the Apache License, Version 2.0 (the "License");
|
|
193
|
+
you may not use this file except in compliance with the License.
|
|
194
|
+
You may obtain a copy of the License at
|
|
195
|
+
|
|
196
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
197
|
+
|
|
198
|
+
Unless required by applicable law or agreed to in writing, software
|
|
199
|
+
distributed under the License is distributed on an "AS IS" BASIS,
|
|
200
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
201
|
+
See the License for the specific language governing permissions and
|
|
202
|
+
limitations under the License.
|
package/README.md
ADDED
|
@@ -0,0 +1,259 @@
|
|
|
1
|
+
# @nage-api/testing
|
|
2
|
+
|
|
3
|
+
The shared test kit (PLAN.md §19, §24 Phase 9).
|
|
4
|
+
|
|
5
|
+
Depends on `@nage-api/contracts` and nothing else — no test runner, no driver, no
|
|
6
|
+
Docker. That constraint is what makes it usable from every other package
|
|
7
|
+
without creating a cycle, and it shapes most of the design decisions below.
|
|
8
|
+
|
|
9
|
+
## What's in it
|
|
10
|
+
|
|
11
|
+
| | |
|
|
12
|
+
| ----------------------- | --------------------------------------------------------------------------------------- |
|
|
13
|
+
| **Security packs** | Cases a whole class of implementation must pass, parameterised over an injected harness |
|
|
14
|
+
| **`expectNoSecrets`** | The leak check, done properly: non-enumerable `Error` fields, encodings, cycles |
|
|
15
|
+
| **Fixtures** | Deterministic builders — a suite cannot fail once a month at midnight |
|
|
16
|
+
| **Port doubles** | Real implementations of the framework's ports |
|
|
17
|
+
| **Envelope assertions** | The three things every e2e test asserts about a response |
|
|
18
|
+
| **Container harness** | Pinned images, retry, parallel-safe — and a clean skip with no Docker |
|
|
19
|
+
|
|
20
|
+
## Security packs
|
|
21
|
+
|
|
22
|
+
A pack is the case list, not the wiring. You supply a harness that knows how to
|
|
23
|
+
drive your implementation; the pack supplies the attacks.
|
|
24
|
+
|
|
25
|
+
```ts
|
|
26
|
+
import { describeQueryAllowList, type TestApi } from '@nage-api/testing';
|
|
27
|
+
import { afterEach, beforeEach, describe, expect, it } from 'vitest';
|
|
28
|
+
|
|
29
|
+
import { parseQuery } from '@nage-api/data';
|
|
30
|
+
import { policy } from './widget.policy.js';
|
|
31
|
+
|
|
32
|
+
// The injected runner — see "Why the runner is injected" below.
|
|
33
|
+
const api: TestApi = { describe, it, beforeEach, afterEach, expect };
|
|
34
|
+
|
|
35
|
+
describeQueryAllowList(api, {
|
|
36
|
+
name: 'parseQuery',
|
|
37
|
+
parse: (query) => parseQuery(query, policy),
|
|
38
|
+
forbiddenField: 'cost_price',
|
|
39
|
+
allowedField: 'name',
|
|
40
|
+
maxLimit: 50,
|
|
41
|
+
allowedOperators: ['eq', 'gt'],
|
|
42
|
+
// Only operators the policy really refuses. `ne` is in `DEFAULT_OPERATORS`, so
|
|
43
|
+
// listing it here against a policy that does not narrow `operators` fails the
|
|
44
|
+
// case — and the failure is the pack's, not the parser's.
|
|
45
|
+
forbiddenOperators: ['regexp', '$where'],
|
|
46
|
+
});
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
The four packs:
|
|
50
|
+
|
|
51
|
+
- **`describeQueryAllowList`** — a forbidden field at the top level, nested in
|
|
52
|
+
`and`/`or`, and nested twice; `limit: -1`, above the ceiling, _at_ the ceiling
|
|
53
|
+
(must pass), non-numeric; a negative offset; `__proto__` and `constructor` as
|
|
54
|
+
keys; each allowed and forbidden operator.
|
|
55
|
+
- **`describeAuthzBypass`** — no credential, the wrong grant, empty roles and
|
|
56
|
+
permissions, and look-alike grants that differ only by case, substring or
|
|
57
|
+
whitespace. Also asserts a refusal names neither the missing grant nor the
|
|
58
|
+
target, since a precise "403 you lack `billing:admin` on invoice 41" is an
|
|
59
|
+
enumeration oracle.
|
|
60
|
+
|
|
61
|
+
The look-alike cases substitute into the **authorised** principal, not the
|
|
62
|
+
unauthorised one. It reads backwards until you try it the other way: a guard
|
|
63
|
+
that also consults a store refuses an unauthorised id on the store check, never
|
|
64
|
+
reaches the grant comparison, and passes the case while still granting `admin`
|
|
65
|
+
to a stored principal whose role is `administrator-readonly`. Conversely, a
|
|
66
|
+
surface that re-derives grants from a store — a resolver in front of a guard —
|
|
67
|
+
cannot be attacked through the credential at all; the pack detects that shape
|
|
68
|
+
by stripping the grants first, and covers it with `forgedClaims` instead.
|
|
69
|
+
|
|
70
|
+
- **`describeUploadValidation`** — the nine files in `MALICIOUS_UPLOADS`: PHP
|
|
71
|
+
bytes behind a `.png` name, a double extension, an SVG, HTML behind
|
|
72
|
+
`image/png`, an empty file, a traversal filename, a name whose real extension
|
|
73
|
+
hides behind a separator, a truncated magic number, and a type outside the
|
|
74
|
+
allow-list. Then JPEG bytes declared as `image/png`, and `shell.PHP` in capitals
|
|
75
|
+
for a denied-extension check written case-sensitively. Plus a control case,
|
|
76
|
+
because a validator that refuses everything passes an all-negative suite.
|
|
77
|
+
- **`describeErrorNonLeakage`** — the operator detail, error metadata and cause
|
|
78
|
+
chain must not reach the client; a non-empty safe message and a stable code
|
|
79
|
+
must. Given `toLogRecord`, it also asserts the operator _does_ get the detail —
|
|
80
|
+
redaction that eats the diagnostic is its own defect.
|
|
81
|
+
|
|
82
|
+
Every pack includes at least one case that must **pass**. An assertion suite
|
|
83
|
+
made only of refusals is satisfied by an implementation that refuses everything.
|
|
84
|
+
|
|
85
|
+
### Why the runner is injected
|
|
86
|
+
|
|
87
|
+
The framework standardises on Vitest; generated apps may use Jest (§27.3). A
|
|
88
|
+
pack that imported `vitest` would be unusable in a Jest suite and would put a
|
|
89
|
+
runner in this package's dependencies. So the runner arrives as a `TestApi` — five
|
|
90
|
+
members: `describe`, `it`, `beforeEach`, `afterEach` and an `expect` returning the
|
|
91
|
+
small `Expectation` matcher surface the packs use.
|
|
92
|
+
|
|
93
|
+
Vitest's and Jest's real APIs both satisfy that structurally, so the whole adapter
|
|
94
|
+
is one object literal:
|
|
95
|
+
|
|
96
|
+
```ts
|
|
97
|
+
import { afterEach, beforeEach, describe, expect, it } from 'vitest';
|
|
98
|
+
import type { TestApi } from '@nage-api/testing';
|
|
99
|
+
|
|
100
|
+
export const api: TestApi = { describe, it, beforeEach, afterEach, expect };
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
Pass all five, since a pack is free to use the hooks even if today's ones mostly
|
|
104
|
+
do not. Declaring the constant as `TestApi` rather than passing the literal inline
|
|
105
|
+
is worth the extra line: the assignment is where a runner that has drifted from
|
|
106
|
+
the interface is reported, at the file that owns the adapter rather than at every
|
|
107
|
+
pack call.
|
|
108
|
+
|
|
109
|
+
## `expectNoSecrets`
|
|
110
|
+
|
|
111
|
+
The same defect appears in every package: a password in a validation error, a
|
|
112
|
+
connection string in a health response, a token in a log line. The obvious check
|
|
113
|
+
misses it three ways:
|
|
114
|
+
|
|
115
|
+
```ts
|
|
116
|
+
import { expect } from 'vitest';
|
|
117
|
+
|
|
118
|
+
declare const error: Error;
|
|
119
|
+
declare const password: string;
|
|
120
|
+
|
|
121
|
+
expect(JSON.stringify(error)).not.toContain(password); // passes on a leak
|
|
122
|
+
```
|
|
123
|
+
|
|
124
|
+
- **Non-enumerable fields.** `Error.message`, `Error.stack` and `cause` do not
|
|
125
|
+
survive a JSON round trip — exactly the fields most likely to hold the leak.
|
|
126
|
+
- **Encodings.** A secret survives as base64, base64url or URL-encoded text.
|
|
127
|
+
- **Cycles.** A serialiser that throws on a cyclic object turns a security
|
|
128
|
+
assertion into an unrelated failure, and the leak goes unchecked.
|
|
129
|
+
|
|
130
|
+
```ts
|
|
131
|
+
import { RecordingLogger, expectNoSecrets } from '@nage-api/testing';
|
|
132
|
+
|
|
133
|
+
// The response the test just made, and the credentials it was built from.
|
|
134
|
+
declare const response: { body: unknown };
|
|
135
|
+
declare const password: string;
|
|
136
|
+
declare const refreshToken: string;
|
|
137
|
+
declare const logger: RecordingLogger;
|
|
138
|
+
|
|
139
|
+
expectNoSecrets(response.body, [password, refreshToken], 'client payload');
|
|
140
|
+
expectNoSecrets(logger.entries, [password], 'log');
|
|
141
|
+
```
|
|
142
|
+
|
|
143
|
+
The failure message masks what it found — via the exported `mask()` — including
|
|
144
|
+
the excerpt of scanned text. A CI log is where secrets go to live forever, and a
|
|
145
|
+
_failing_ leak assertion must not be the thing that puts one there.
|
|
146
|
+
|
|
147
|
+
## Fixtures
|
|
148
|
+
|
|
149
|
+
Deterministic, and counter-based rather than stateful-random: `hash32(seed,
|
|
150
|
+
index)` means inserting a fixture at the top of a suite does not renumber every
|
|
151
|
+
id below it, so a diff stays readable.
|
|
152
|
+
|
|
153
|
+
```ts
|
|
154
|
+
import { authUser, fixtureDate, fixtures, paginated } from '@nage-api/testing';
|
|
155
|
+
|
|
156
|
+
declare const records: readonly { readonly id: string }[];
|
|
157
|
+
|
|
158
|
+
const user = authUser({ roles: ['editor'] }); // overrides say what the test is about
|
|
159
|
+
const page = paginated(records); // count derived from the records
|
|
160
|
+
const oneMinuteIn = fixtureDate(60_000); // fixed epoch + offset
|
|
161
|
+
const scoped = fixtures(7); // an independent sequence per suite
|
|
162
|
+
```
|
|
163
|
+
|
|
164
|
+
Dates are anchored to `FIXTURE_EPOCH_MS`, so no test depends on the wall clock.
|
|
165
|
+
Emails use `example.test` (RFC 2606), so a fixture can never send real mail.
|
|
166
|
+
`paginated` derives `count` from the records it was given: a fixture that
|
|
167
|
+
accepted a blind count could describe an impossible page, and a test asserting
|
|
168
|
+
on pagination would be asserting on the lie.
|
|
169
|
+
|
|
170
|
+
## Port doubles
|
|
171
|
+
|
|
172
|
+
`FakeClock`, `RecordingLogger`, `MemoryKeyValueStore`, `MemoryRateLimitStore`,
|
|
173
|
+
`StubSecretProvider`. Mocked at the **port** boundary, never at ORM internals
|
|
174
|
+
(§19).
|
|
175
|
+
|
|
176
|
+
Each is a complete implementation, not a stub that returns `undefined`. That
|
|
177
|
+
distinction is the point: a stub agrees with whatever the code under test does,
|
|
178
|
+
so a test built on one passes even when the code is wrong. `MemoryRateLimitStore`
|
|
179
|
+
is a real fixed-window counter that actually refuses — a guard tested against a
|
|
180
|
+
permissive double is a guard nobody has tested. `StubSecretProvider.require`
|
|
181
|
+
rejects for a missing name, exactly as the env and AWS providers do.
|
|
182
|
+
|
|
183
|
+
`RecordingLogger.child()` shares its parent's `entries` array, so a test can
|
|
184
|
+
assert nothing in the whole logger tree leaked a credential without having to
|
|
185
|
+
know which children the code created.
|
|
186
|
+
|
|
187
|
+
## Container harness
|
|
188
|
+
|
|
189
|
+
`testcontainers` is **not** a dependency — this package must stay installable
|
|
190
|
+
without Docker. The runtime is a port:
|
|
191
|
+
|
|
192
|
+
<!-- docs-example: fragment -->
|
|
193
|
+
|
|
194
|
+
```ts
|
|
195
|
+
import { describe, it } from 'vitest';
|
|
196
|
+
import { ContainerHarness, describeWithContainers, type ContainerRuntime } from '@nage-api/testing';
|
|
197
|
+
|
|
198
|
+
// The adapter over `testcontainers` — or over anything else that starts a
|
|
199
|
+
// container — that the project supplies. `unavailableRuntime` is the default.
|
|
200
|
+
declare const dockerRuntime: ContainerRuntime;
|
|
201
|
+
|
|
202
|
+
const harness = new ContainerHarness({ runtime: dockerRuntime });
|
|
203
|
+
|
|
204
|
+
await describeWithContainers(
|
|
205
|
+
{ describe, it },
|
|
206
|
+
{
|
|
207
|
+
name: 'postgres driver conformance',
|
|
208
|
+
harness,
|
|
209
|
+
suite: () => {
|
|
210
|
+
/* … */
|
|
211
|
+
},
|
|
212
|
+
},
|
|
213
|
+
);
|
|
214
|
+
```
|
|
215
|
+
|
|
216
|
+
Three mitigations for the flakiness §24 names, all structural rather than
|
|
217
|
+
remembered: images are pinned to exact patch versions in `IMAGES` (a floating
|
|
218
|
+
`postgres:16` is a different image next month); `start` retries with exponential
|
|
219
|
+
backoff; and every container gets a process-wide unique name plus an ephemeral
|
|
220
|
+
port, so two suites running at once cannot collide.
|
|
221
|
+
|
|
222
|
+
Without a runtime the suite skips **loudly** — the suite title says it skipped
|
|
223
|
+
and why, and it leaves a passing marker test behind, because a silently skipped
|
|
224
|
+
suite is indistinguishable from a passing one. `required: true` turns the skip
|
|
225
|
+
into a failure, for the CI job that is supposed to have Docker.
|
|
226
|
+
|
|
227
|
+
## Two deliberate deviations from §19
|
|
228
|
+
|
|
229
|
+
**No in-memory repository.** §19 lists an in-memory driver as part of this
|
|
230
|
+
package. `@nage-api/data` already ships `MemoryRepository`, and it is the one the
|
|
231
|
+
driver conformance suite runs against — so it is the only in-memory repository
|
|
232
|
+
whose behaviour is _proven_ to match a real driver's. A second copy here would
|
|
233
|
+
have no such guarantee, and this package sits below `@nage-api/data` in the
|
|
234
|
+
dependency graph and may not import it. Use `MemoryRepository` from `@nage-api/data`.
|
|
235
|
+
|
|
236
|
+
**The container adapter has never been exercised against Docker.** There is no
|
|
237
|
+
container runtime in this development environment. `ContainerHarness` is
|
|
238
|
+
unit-tested against a fake runtime — retry, backoff, naming, teardown, the skip
|
|
239
|
+
and the required-failure paths are all covered — but no test in this repository
|
|
240
|
+
has started a real container. The first project to supply a `testcontainers`
|
|
241
|
+
adapter is exercising that path for the first time.
|
|
242
|
+
|
|
243
|
+
## Testing the kit
|
|
244
|
+
|
|
245
|
+
174 tests, and the most valuable of them are in `test/packs.spec.ts`, which runs
|
|
246
|
+
every pack twice: against a compliant subject, where each case must pass, and
|
|
247
|
+
against subjects broken in one named way each, where the pack must fail **on the
|
|
248
|
+
case that names the defect**. A pack that quietly passes a broken implementation
|
|
249
|
+
is worse than no pack, because it produces a green suite as evidence — and only
|
|
250
|
+
this kind of test can tell the two apart. It is also what proves each case is not
|
|
251
|
+
decorative: the off-by-one-ceiling subject exists to show why the pack asserts
|
|
252
|
+
that a limit _at_ the maximum is accepted, and the refuses-everything subject
|
|
253
|
+
exists to show why every pack needs a control case.
|
|
254
|
+
|
|
255
|
+
The suite has caught three real defects in the kit's own code so far:
|
|
256
|
+
`expectNoSecrets` printing the raw secret into its own failure message,
|
|
257
|
+
`ContainerHarness` handing two containers the same name when both started inside
|
|
258
|
+
one millisecond, and the authorization pack's look-alike cases passing for the
|
|
259
|
+
wrong reason against any store-backed guard.
|
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Assertions about the response envelope (PLAN.md §16.1, §19).
|
|
3
|
+
*
|
|
4
|
+
* Every e2e test in every package makes the same three assertions about a
|
|
5
|
+
* response — that it is an envelope, that it carries the correlation id, and
|
|
6
|
+
* that an error's `code` is the stable one. Writing them by hand each time is
|
|
7
|
+
* how a test ends up asserting `response.body.data` exists while quietly
|
|
8
|
+
* accepting `success: false`.
|
|
9
|
+
*
|
|
10
|
+
* These throw plain `Error`s, so they work in any runner and inside a pack.
|
|
11
|
+
*
|
|
12
|
+
* The input is a real HTTP body, so it is modelled as one: `LooseEnvelope`
|
|
13
|
+
* describes what *might* be there rather than what should be. Casting straight to
|
|
14
|
+
* `ApiResponse` would make the checks below look redundant to the type checker
|
|
15
|
+
* while remaining exactly as necessary at runtime — the assertion would then be
|
|
16
|
+
* "the cast said so", which is no assertion at all.
|
|
17
|
+
*/
|
|
18
|
+
import type { ErrorCode, ErrorResponse } from '@nage-api/contracts';
|
|
19
|
+
/**
|
|
20
|
+
* Narrow a body to a success envelope, or throw with what it actually was.
|
|
21
|
+
*
|
|
22
|
+
* @returns the `data` member, so a caller can chain straight into assertions
|
|
23
|
+
*/
|
|
24
|
+
export declare function assertSuccessEnvelope(body: unknown): unknown;
|
|
25
|
+
/**
|
|
26
|
+
* Narrow a body to an error envelope and, optionally, assert its code.
|
|
27
|
+
*
|
|
28
|
+
* The code is what clients program against (§17), so asserting on it rather than
|
|
29
|
+
* on the message is the difference between a test that survives a copy edit and
|
|
30
|
+
* one that does not.
|
|
31
|
+
*/
|
|
32
|
+
export declare function assertErrorEnvelope(body: unknown, expectedCode?: ErrorCode): ErrorResponse;
|
|
33
|
+
/**
|
|
34
|
+
* Assert the envelope carries the correlation id the caller sent.
|
|
35
|
+
*
|
|
36
|
+
* This is the property §18 exists for: one id in the response, the log lines and
|
|
37
|
+
* any job the request spawned. A test that never checks it is how the id
|
|
38
|
+
* silently stops being propagated.
|
|
39
|
+
*/
|
|
40
|
+
export declare function assertCorrelated(body: unknown, expectedRequestId?: string): string;
|
|
41
|
+
/** Assert a paginated envelope's counters are consistent with its page. */
|
|
42
|
+
export declare function assertPaginated(body: unknown, expectedCount?: number): void;
|
|
43
|
+
//# sourceMappingURL=envelope.d.ts.map
|
|
@@ -0,0 +1,116 @@
|
|
|
1
|
+
"use strict";
|
|
2
|
+
/**
|
|
3
|
+
* Assertions about the response envelope (PLAN.md §16.1, §19).
|
|
4
|
+
*
|
|
5
|
+
* Every e2e test in every package makes the same three assertions about a
|
|
6
|
+
* response — that it is an envelope, that it carries the correlation id, and
|
|
7
|
+
* that an error's `code` is the stable one. Writing them by hand each time is
|
|
8
|
+
* how a test ends up asserting `response.body.data` exists while quietly
|
|
9
|
+
* accepting `success: false`.
|
|
10
|
+
*
|
|
11
|
+
* These throw plain `Error`s, so they work in any runner and inside a pack.
|
|
12
|
+
*
|
|
13
|
+
* The input is a real HTTP body, so it is modelled as one: `LooseEnvelope`
|
|
14
|
+
* describes what *might* be there rather than what should be. Casting straight to
|
|
15
|
+
* `ApiResponse` would make the checks below look redundant to the type checker
|
|
16
|
+
* while remaining exactly as necessary at runtime — the assertion would then be
|
|
17
|
+
* "the cast said so", which is no assertion at all.
|
|
18
|
+
*/
|
|
19
|
+
Object.defineProperty(exports, "__esModule", { value: true });
|
|
20
|
+
exports.assertSuccessEnvelope = assertSuccessEnvelope;
|
|
21
|
+
exports.assertErrorEnvelope = assertErrorEnvelope;
|
|
22
|
+
exports.assertCorrelated = assertCorrelated;
|
|
23
|
+
exports.assertPaginated = assertPaginated;
|
|
24
|
+
/**
|
|
25
|
+
* Narrow a body to a success envelope, or throw with what it actually was.
|
|
26
|
+
*
|
|
27
|
+
* @returns the `data` member, so a caller can chain straight into assertions
|
|
28
|
+
*/
|
|
29
|
+
function assertSuccessEnvelope(body) {
|
|
30
|
+
const envelope = requireEnvelope(body);
|
|
31
|
+
if (envelope.success !== true) {
|
|
32
|
+
throw new Error(`Expected a success envelope but got an error: ${describe(envelope.error?.code, 'unknown')} — ${describe(envelope.error?.message, 'no message')}`);
|
|
33
|
+
}
|
|
34
|
+
if (!('data' in envelope)) {
|
|
35
|
+
throw new Error('A success envelope must carry a `data` member');
|
|
36
|
+
}
|
|
37
|
+
return envelope.data;
|
|
38
|
+
}
|
|
39
|
+
/**
|
|
40
|
+
* Narrow a body to an error envelope and, optionally, assert its code.
|
|
41
|
+
*
|
|
42
|
+
* The code is what clients program against (§17), so asserting on it rather than
|
|
43
|
+
* on the message is the difference between a test that survives a copy edit and
|
|
44
|
+
* one that does not.
|
|
45
|
+
*/
|
|
46
|
+
function assertErrorEnvelope(body, expectedCode) {
|
|
47
|
+
const envelope = requireEnvelope(body);
|
|
48
|
+
if (envelope.success !== false) {
|
|
49
|
+
throw new Error('Expected an error envelope but the response reported success');
|
|
50
|
+
}
|
|
51
|
+
const code = envelope.error?.code;
|
|
52
|
+
if (typeof code !== 'string' || typeof envelope.error?.message !== 'string') {
|
|
53
|
+
throw new Error('An error envelope must carry `error.code` and `error.message`');
|
|
54
|
+
}
|
|
55
|
+
if (expectedCode !== undefined && code !== expectedCode) {
|
|
56
|
+
throw new Error(`Expected error code ${expectedCode} but got ${code}`);
|
|
57
|
+
}
|
|
58
|
+
return envelope;
|
|
59
|
+
}
|
|
60
|
+
/**
|
|
61
|
+
* Assert the envelope carries the correlation id the caller sent.
|
|
62
|
+
*
|
|
63
|
+
* This is the property §18 exists for: one id in the response, the log lines and
|
|
64
|
+
* any job the request spawned. A test that never checks it is how the id
|
|
65
|
+
* silently stops being propagated.
|
|
66
|
+
*/
|
|
67
|
+
function assertCorrelated(body, expectedRequestId) {
|
|
68
|
+
const envelope = requireEnvelope(body);
|
|
69
|
+
const requestId = envelope.meta?.requestId;
|
|
70
|
+
if (typeof requestId !== 'string' || requestId === '') {
|
|
71
|
+
throw new Error('An envelope must carry `meta.requestId`');
|
|
72
|
+
}
|
|
73
|
+
if (expectedRequestId !== undefined && requestId !== expectedRequestId) {
|
|
74
|
+
throw new Error(`Expected requestId ${expectedRequestId} but the envelope carried ${requestId}`);
|
|
75
|
+
}
|
|
76
|
+
return requestId;
|
|
77
|
+
}
|
|
78
|
+
/** Assert a paginated envelope's counters are consistent with its page. */
|
|
79
|
+
function assertPaginated(body, expectedCount) {
|
|
80
|
+
const envelope = requireEnvelope(body);
|
|
81
|
+
const pagination = envelope.meta?.pagination;
|
|
82
|
+
if (pagination === undefined) {
|
|
83
|
+
throw new Error('A paginated envelope must carry `meta.pagination`');
|
|
84
|
+
}
|
|
85
|
+
const data = envelope.data;
|
|
86
|
+
if (!Array.isArray(data)) {
|
|
87
|
+
throw new Error('A paginated envelope must carry an array in `data`');
|
|
88
|
+
}
|
|
89
|
+
const limit = pagination.limit;
|
|
90
|
+
if (typeof limit === 'number' && data.length > limit) {
|
|
91
|
+
// The specific defect an enforced `maxLimit` exists to prevent (§12): a page
|
|
92
|
+
// larger than the limit means the ceiling was not applied.
|
|
93
|
+
throw new Error(`A page of ${String(data.length)} records exceeds its own limit of ${String(limit)}`);
|
|
94
|
+
}
|
|
95
|
+
if (expectedCount !== undefined && pagination.count !== expectedCount) {
|
|
96
|
+
throw new Error(`Expected a count of ${String(expectedCount)} but got ${String(pagination.count)}`);
|
|
97
|
+
}
|
|
98
|
+
}
|
|
99
|
+
/** Render an untrusted member for a message without risking `[object Object]`. */
|
|
100
|
+
function describe(value, fallback) {
|
|
101
|
+
if (value === undefined || value === null)
|
|
102
|
+
return fallback;
|
|
103
|
+
return typeof value === 'string' ? value : JSON.stringify(value);
|
|
104
|
+
}
|
|
105
|
+
function requireEnvelope(body) {
|
|
106
|
+
if (typeof body !== 'object' || body === null) {
|
|
107
|
+
throw new Error(`Expected an envelope object but got ${typeof body}`);
|
|
108
|
+
}
|
|
109
|
+
if (!('success' in body)) {
|
|
110
|
+
// Usually means the route is decorated `@NoEnvelope()`, which is worth
|
|
111
|
+
// saying out loud rather than failing on a missing `data`.
|
|
112
|
+
throw new Error('Expected an envelope with a `success` member; the route may be marked @NoEnvelope()');
|
|
113
|
+
}
|
|
114
|
+
return body;
|
|
115
|
+
}
|
|
116
|
+
//# sourceMappingURL=envelope.js.map
|