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
Copy file name to clipboardExpand all lines: docs/adr/0011-api-e2e-test-architecture.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,13 +6,13 @@
6
6
7
7
## Context
8
8
9
-
We need to catch regressions on the API on `main` sooner (auth, routing, validation, and the sync HTTP response contract) without waiting for a consumer to hit a break. Relying on manually running the script every time is hard and not reliable. It pollutes staging data, depends on ambient fixtures, and does not work as a team habit.
9
+
We want to catch API regressions on main sooner (auth, routing, validation, and the synchronous HTTP response contract) instead of waiting for a consumer to hit a problem. Manually running the test script is easy to forget, pollutes staging data, depends on existing fixtures, and is not something we can rely on as a team.
10
10
11
-
A fuller API e2e harness in the server test setup (PR CI, isolated fixtures, typed asserts) is planned and sits in the backlog. Until that is ready, we need a short-term automated check that is isolated from staging data and cheap to operate.
11
+
A more complete API e2e harness in the server test setup (PR CI, isolated fixtures, typed assertions) is planned for future work. Until then, we need a simple automated check that runs against an isolated environment and gives us confidence that the deployed API is still working as expected.
12
12
13
-
**Focus for now is the Public API.** Those endpoints are consumed outside the product, so we need a minimum unbroken contract there first. Internal API routes are not the priority for these tests; we can add coverage for them later when there is a real need, using the same stack and suite pattern.
13
+
The first test suite covers the Public API. These endpoints are the external contract our consumers rely on, so they are the best place to start. We can add more API e2e suites over time using the same runtime and suite pattern as needed.
14
14
15
-
This ADR is the **runtime and isolation** decision. How e2e test cases are written lives in [ADR-0012](./0012-api-e2e-test-suite-design.md). Current suite:[`.github/scripts/public-api-e2e-tests.sh`](../../.github/scripts/public-api-e2e-tests.sh).
15
+
This ADR covers the runtime and isolation architecture for API e2e tests. The design of the test suites themselves is covered in [ADR-0012](./0012-api-e2e-test-suite-design.md). The current suite lives in[`.github/scripts/public-api-e2e-tests.sh`](../../.github/scripts/public-api-e2e-tests.sh).
16
16
17
17
## Decision
18
18
@@ -78,7 +78,7 @@ A single shared `api-e2e` cannot safely gate concurrent PRs, because deploys and
78
78
79
79
### Database reset (ops)
80
80
81
-
[`reset_api_e2e_test_db.sh`](../../reset_api_e2e_test_db.sh) runs on the EC2 host used to reach staging Postgres over SSH. It creates `crowd_api_e2e` if needed, applies normal Flyway migrations, truncates tables, and seeds the default tenant.
81
+
`reset_api_e2e_test_db.sh` runs on the EC2 host used to reach staging Postgres over SSH. It creates `crowd_api_e2e` if needed, applies normal Flyway migrations, truncates tables, and seeds the default tenant.
82
82
83
83
Run it after migrations land on `main`, or when leftover e2e test rows should be cleared. Keep that host’s crowd.dev checkout on latest `main` so Flyway matches the deployed `api-e2e`.
Copy file name to clipboardExpand all lines: docs/adr/0012-api-e2e-test-suite-design.md
+5-6Lines changed: 5 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,17 +6,17 @@
6
6
7
7
## Context
8
8
9
-
API e2e tests need a maintainable HTTP suite that can grow as endpoints are added. For now the suite covers the **Public API** (see [ADR-0011](./0011-api-e2e-test-architecture.md)); the same writing pattern should hold if we later add internal API e2e tests when there is a real need.
9
+
API e2e tests need a maintainable HTTP suite pattern that can grow as endpoints are added. Without shared structure, suites tend to split by HTTP method, accumulate one-off asserts, and become hard to extend or review.
10
10
11
-
Without a shared structure, suites tend to split by HTTP method, accumulate one-off asserts, and become hard to extend or review. We want a thin, boring pattern: shared helpers, clear grouping, and an obvious place to add the next resource. This is how we write durable e2e cases until a fuller PR-time API e2e harness exists (backlog).
11
+
We want a thin, boring pattern: shared helpers, clear grouping, and an obvious place to add the next resource. This is how we write durable e2e cases until a fuller PR-time API e2e harness exists (backlog).
12
12
13
-
This ADR is the **suite design** (how tests are written). Runtime, isolation, scheduled CI, and ops live in [ADR-0011](./0011-api-e2e-test-architecture.md).
13
+
This ADR is the **suite design** (how tests are written). Runtime, isolation, scheduled CI, which surfaces we cover, and ops live in [ADR-0011](./0011-api-e2e-test-architecture.md).
14
14
15
15
## Decision
16
16
17
-
Implement API e2e tests as HTTP bash script(s) with this structure. Current entrypoint: [`.github/scripts/public-api-e2e-tests.sh`](../../.github/scripts/public-api-e2e-tests.sh) (Public API). New surfaces should reuse this pattern (same script or additional scripts), not invent a parallel style.
17
+
Implement API e2e tests as HTTP bash script(s) with this structure. Current entrypoint: [`.github/scripts/public-api-e2e-tests.sh`](../../.github/scripts/public-api-e2e-tests.sh). New suites should reuse this pattern (same script or additional scripts), not invent a parallel style.
18
18
19
-
The suite is **regression-oriented and intentionally thin**: contract and critical flows over HTTP, not a full matrix of edge cases.
19
+
The suite is **thin**: assert the HTTP contract and critical flows so regressions show up early. Leave exhaustive edge-case matrices to unit or focused contract tests.
20
20
21
21
| Layer | Role |
22
22
| --- | --- |
@@ -61,7 +61,6 @@ The suite is **regression-oriented and intentionally thin**: contract and critic
61
61
- Adding an endpoint is: open (or create) the resource suite, add `api` + `check`, register in `main` if new.
62
62
- Reviews focus on cases, not harness inventiveness.
63
63
- Soft `check` keeps the run going so one failure does not hide the rest.
64
-
- Public API suites land first; internal API can follow the same rules later without a new design debate.
0 commit comments