MF-6: Cross-adapter ForgePort conformance suite

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

charles/claude-hooks#297

code-lead commented

2026-04-23 23:33:15 +00:00

Collaborator

As a platform engineer, I want one test file that exercises every ForgePort method against every adapter, so that any new method added to the port must pass on all three forges before the PR merges.

Emerges alongside MF-1 — the harness is factored out of the first non-Forgejo adapter's tests once it exists, not written speculatively before.

Acceptance criteria

Harness

New apps/server/src/infrastructure/forge/forge-port-conformance.test.ts.
Parameterised over { forgejo, github, gitlab } (gitlab slot ready even if MF-2 hasn't landed — the parameter set is extensible).
Each test exercises a single ForgePort method against recorded fixtures — no live API traffic.

Fixtures

Fixtures live under apps/server/test/fixtures/forge/{forge}/{scenario}.json.
Naming: one file per scenario, not per method; e.g., happy-get-issue.json, rate-limit-list-issues.json.
Fixtures captured from real responses (redacted) so future API drift shows up as test failures.

Scenarios per method

Happy path.
Auth failure (401 / 403).
Not-found (404).
Rate limit (429 / X-RateLimit-Remaining: 0).
Pagination (multi-page list results).

CI

just qa runs the conformance suite on every PR.
Failures name the adapter + scenario + method that broke so the regressing change is obvious.

Documentation

Short README next to the fixtures explaining how to re-record one (point at a small CLI recipe using the service token in a dry-run mode).

Out of scope

Live-network contract tests — optional, runnable via a separate recipe (just forge-live) as a follow-up.
Property-based testing — not needed; scenarios cover the failure modes the service cares about.

References

Spec: specs/multi-forge.md § MF-6.
apps/server/src/infrastructure/forge/forgejo-port.ts — source of truth for the method surface under test.
MF-1 GitHub adapter — the first non-Forgejo adapter and the impetus for extracting this harness.

Emerges alongside MF-1. The harness is extracted from MF-1's adapter tests once a second (non-Forgejo) implementation exists. MF-1 is the direct predecessor.

Depends on #292 (MF-1)

As a platform engineer, I want one test file that exercises every `ForgePort` method against every adapter, so that any new method added to the port must pass on all three forges before the PR merges. Emerges **alongside MF-1** — the harness is factored out of the first non-Forgejo adapter's tests once it exists, not written speculatively before. ## Acceptance criteria ### Harness - [ ] New `apps/server/src/infrastructure/forge/forge-port-conformance.test.ts`. - [ ] Parameterised over `{ forgejo, github, gitlab }` (gitlab slot ready even if MF-2 hasn't landed — the parameter set is extensible). - [ ] Each test exercises a single `ForgePort` method against recorded fixtures — no live API traffic. ### Fixtures - [ ] Fixtures live under `apps/server/test/fixtures/forge/{forge}/{scenario}.json`. - [ ] Naming: one file per scenario, not per method; e.g., `happy-get-issue.json`, `rate-limit-list-issues.json`. - [ ] Fixtures captured from real responses (redacted) so future API drift shows up as test failures. ### Scenarios per method - [ ] Happy path. - [ ] Auth failure (401 / 403). - [ ] Not-found (404). - [ ] Rate limit (429 / `X-RateLimit-Remaining: 0`). - [ ] Pagination (multi-page list results). ### CI - [ ] `just qa` runs the conformance suite on every PR. - [ ] Failures name the adapter + scenario + method that broke so the regressing change is obvious. ### Documentation - [ ] Short README next to the fixtures explaining how to re-record one (point at a small CLI recipe using the service token in a dry-run mode). ## Out of scope - Live-network contract tests — optional, runnable via a separate recipe (`just forge-live`) as a follow-up. - Property-based testing — not needed; scenarios cover the failure modes the service cares about. ## References - Spec: [`specs/multi-forge.md`](../src/branch/main/specs/multi-forge.md) § MF-6. - `apps/server/src/infrastructure/forge/forgejo-port.ts` — source of truth for the method surface under test. - MF-1 GitHub adapter — the first non-Forgejo adapter and the impetus for extracting this harness. ## Dependencies - **Emerges alongside MF-1**. The harness is extracted from MF-1's adapter tests once a second (non-Forgejo) implementation exists. MF-1 is the direct predecessor.  - Depends on #292 (MF-1)

code-lead added the

labels

dev was assigned by code-lead

code-lead referenced this issue

2026-04-23 23:34:18 +00:00

MF-2: GitLab adapter for ForgePort #293

2026-04-23 23:34:47 +00:00

Tracking: multi-forge spec breakdown (Forgejo + GitHub + GitLab behind ForgePort) #291

charles referenced this issue from a commit

2026-04-24 09:48:32 +00:00

test(forge): cross-adapter ForgePort conformance suite (MF-6)

claude-desktop referenced this issue from a pull request that will close it,