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
{{ message }}
Repository navigation
Commit c5dbf09
Browse filesBrowse the repository at this point in the historyBrowse files
- Postman v11.34.5 (used for creating and running Postman collections)
14
13
- Node.js >= v16
15
14
- Newman >= v6 (used for running Postman collections in CLI)
16
15
17
16
## Setup
18
-
- Import the Postman collection `Atum-Service_LOCAL_env.postman_environment.json` into Postman.
19
-
- This file will set up env variables.
17
+
18
+
- Import the Postman collection `Atum-Service_LOCAL_env.postman_environment.json` into Postman.
19
+
- This file will set up env variables.
20
20
- Import the Postman collections for `1-shot` test:
21
-
-`1_shot/Atum-Service_1-Shot_test_flow.postman_collection.json` (the only collection in this directory)
22
-
- A **flow** collection: its folders run in sequence from the top to the bottom, each folder is one named test with its own preparations.
23
-
- Covers the health endpoints, the v2 partitioning, ancestors, additional data, checkpoint and flow endpoints, the deprecated v1 `createPartitioning` / `createCheckpoint` calls and, in the last folder, the consolidated POST and linking behaviour of v1.1 (see [Coverage of the v1.1 folder](#coverage-of-the-v11-folder)).
21
+
-`1_shot/Atum-Service_1-Shot_test_flow.postman_collection.json` (the only collection in this directory)
22
+
- A **flow** collection: its folders run in sequence from the top to the bottom, each folder is one named test
23
+
with its own preparations.
24
+
- Covers the health endpoints, the v2 partitioning, ancestors, additional data, checkpoint and flow endpoints,
25
+
and the deprecated v1 `createPartitioning` / `createCheckpoint` calls.
24
26
25
27
## Backup
26
-
- Export the Postman collections and replace the current ones in the project repository. (Rename to avoid spaces in the file name)
27
-
- Why: To have a backup of the current state of the collections.
28
+
29
+
- Export the Postman collections and replace the current ones in the project repository. (Rename to avoid spaces in the
30
+
file name)
31
+
- Why: To have a backup of the current state of the collections.
28
32
- Each collection is exported separately.
29
33
30
34
## Collection Types
35
+
31
36
Note: Each Postman collection run in sequence from the top to the bottom.
32
37
33
38
-**Flow**:
@@ -39,20 +44,23 @@ Note: Each Postman collection run in sequence from the top to the bottom.
39
44
- split multiple tests related to one flow
40
45
41
46
## Terms
47
+
42
48
-`1-shot` category: Each REST API endpoint should be covered here only one call (ideally).
43
49
- Why: To reach the goal of the minimalist test with coverage of all published application endpoints.
44
50
- Goal: All requests have to pass without any error. Test should be defined with this goal.
45
51
46
52
## Run Tests
47
53
48
54
### Local Using Postman
55
+
49
56
- Open Postman.
50
57
- Import the Postman env file.
51
58
- Import the Postman collection.
52
59
- Select the environment for the collection.
53
60
- Run the collection.
54
61
55
62
### Local Using Newman
63
+
56
64
```yaml
57
65
cd api-tests
58
66
@@ -62,30 +70,23 @@ newman run ./1_shot/Atum-Service_1-Shot_test_flow.postman_collection.json \
62
70
```
63
71
64
72
### Running locally (Newman against a local server)
65
-
The collection creates (uniquely named) data, so run it only against a **local or test stack**, never against a shared or production host.
73
+
74
+
The collection creates (uniquely named) data, so run it only against a **local or test stack**, never against a shared
75
+
or production host.
76
+
66
77
The environment file `Atum-Service_LOCAL_env.postman_environment.json` points to `host=http://localhost:8080`.
67
78
68
-
1. Start a PostgreSQL database and migrate it as described in [`database/README.md`](../database/README.md#resetting-a-development-database)
69
-
(a database that already applied an earlier V0.10.0.x migration of the unreleased v1.1 work has to be reset first, `flywayClean` alone is not enough).
79
+
1. Start a PostgreSQL database and migrate it as described in
80
+
[`database/README.md`](../database/README.md#resetting-a-development-database) (a database that already applied an
81
+
earlier V0.10.0.x migration of the unreleased v1.1 work has to be reset first, `flywayClean` alone is not enough).
70
82
2. Start the server (see [`server/README.md`](../server/README.md)); `GET http://localhost:8080/health` has to answer `200`.
71
83
3. Run Newman from this directory:
84
+
72
85
```yaml
73
86
cd api-tests
74
87
75
88
newman run ./1_shot/Atum-Service_1-Shot_test_flow.postman_collection.json \
The run is repeatable against the same database: the first request of the v1.1 folder always generates a fresh `v11_suffix` (`v11_<Date.now()>_<random>`) and clears every other `v11_*` variable, so an aborted earlier run (or a run started in the middle of the folder) cannot leak state into the next one, and every partitioning key of the folder is new. The original folders use `api_tests_<Date.now()>`.
80
-
Requests of the v1.1 folder that need an id captured by an earlier request fail with an explicit "run the folder from its first request" error instead of a misleading assertion when started in the middle. The only fixed ids are the "unknown parent" probes (`9007199254740991`, and `9007199254740000+i` for the 101-id cap); they assume that no database sequence ever reaches that range.
81
-
82
-
### Coverage of the v1.1 folder
83
-
The last folder, `Test: consolidated POST and linking (v1.1)`, is appended after the original folders and uses only its own collection variables (prefix `v11_`); it has 25 requests (the whole collection 49). It is an HTTP-contract smoke test with one happy path per behaviour; boundaries and edge cases (self-link, the 100-parent boundary, an absent copy flag, the PATCH copy-flag matrix, concurrency) are covered by the database and server tests.
84
-
It checks:
85
-
-`POST /api/v2/partitionings` of a new partitioning answers `201` with a `Location` header; the same POST again (even with another author) answers `200`, the same id, the same `Location` and the **stored** author.
86
-
- A single new parent can be linked to an already existing partitioning through the same POST (`200`, same id and `Location`; the ancestors are exactly that parent); a **multi-parent POST** (a new child with two valid parents in one call) puts the child into the flows of both parents.
87
-
- Flow membership is asserted as **exact sets** (the flow of a parent contains exactly the parent, its children and the expected descendants, nothing else), so a leak of an unrelated partitioning into a flow fails the run.
88
-
-**No descendant propagation:** when a partitioning that already has a child is linked under a new parent with `PATCH`, the request is refused with `409` and nothing is written (the new parent's flow is checked to be unchanged, as an exact set).
89
-
-`copyMeasureDefinitions: true` copies the parent measure definitions to a **new** child, `false` copies none; additional data is never copied by the POST.
90
-
- Error contract, one request each: a cycle is rejected with `409` (POST of a partitioning under its own descendant); an unknown parent answers `404` and the child is not created; 101 distinct parents answer `400`; `PATCH /api/v2/partitionings/{id}/ancestors` without the required copy flags answers `400`. Error responses are asserted by status code and envelope shape (`requestId`, `message`), not by the wording of the message.
91
-
-`GET /api/v2/partitionings/{id}/ancestors` answers `200` with the exact set of the direct parents.
0 commit comments