Give tests/pi-provider.sh one function per case #64

Closed
opened 2026-09-22 01:31:03 +01:00 by allod-agent · 0 comments
Member

Bring tests/pi-provider.sh up to the standard its siblings already meet: one function per case, so a failing case is named by a function and a reader can find a scenario without scrolling fifteen hundred lines of straight-line shell.

Primary goals:

  • One function per case — every scenario after the fixture setup becomes a named function, called from a runner at the bottom, the way tests/nexus-host-key.sh and tests/refresh-local-auth.sh are written.
  • The fixture setup is split — the 327-line setup_fixture is broken into the pieces the cases actually share, so a case can say which fixture it needs.
  • Every assertion is preserved — the set of assert_* and pass/fail calls before and after is the same, which is what shows nothing was dropped in the move.
  • Case names are the report — a run prints which case failed, not a line number into a monolith.

Current state and specifics

The file is 2135 lines with 20 functions, all of them helpers: setup_fixture (tests/pi-provider.sh:82-409), setup_legacy_fixture (:410-437), seven run_provider_* wrappers (:438-558) and the assertion helpers. Everything from :574 to the end, about 1560 lines, is one straight-line sequence of cases delimited only by prose comments ("Open-world adapters and model fields, on its own fixture…", "Recovery itself can die after recreating a pruned directory…"). The siblings show the target shape: tests/nexus-host-key.sh is 962 lines in 43 functions and tests/refresh-local-auth.sh is 823 lines in 31, each case a function.

shell.md has the one rule that matters for the runner: a case body must run in a subshell that sets -e itself and reports its status as a plain statement, because if run_case; then suspends set -e for the whole function and turns a failed assertion in the middle into a pass.

Scope

In scope: the case functions, the runner, and the fixture split.

Explicitly not in scope: changing what any case asserts, and the other tests in tests/, which already have the shape.

Bring `tests/pi-provider.sh` up to the standard its siblings already meet: one function per case, so a failing case is named by a function and a reader can find a scenario without scrolling fifteen hundred lines of straight-line shell. Primary goals: - **One function per case** — every scenario after the fixture setup becomes a named function, called from a runner at the bottom, the way `tests/nexus-host-key.sh` and `tests/refresh-local-auth.sh` are written. - **The fixture setup is split** — the 327-line `setup_fixture` is broken into the pieces the cases actually share, so a case can say which fixture it needs. - **Every assertion is preserved** — the set of `assert_*` and `pass`/`fail` calls before and after is the same, which is what shows nothing was dropped in the move. - **Case names are the report** — a run prints which case failed, not a line number into a monolith. ### Current state and specifics The file is 2135 lines with 20 functions, all of them helpers: `setup_fixture` (`tests/pi-provider.sh:82-409`), `setup_legacy_fixture` (`:410-437`), seven `run_provider_*` wrappers (`:438-558`) and the assertion helpers. Everything from `:574` to the end, about 1560 lines, is one straight-line sequence of cases delimited only by prose comments ("Open-world adapters and model fields, on its own fixture…", "Recovery itself can die after recreating a pruned directory…"). The siblings show the target shape: `tests/nexus-host-key.sh` is 962 lines in 43 functions and `tests/refresh-local-auth.sh` is 823 lines in 31, each case a function. `shell.md` has the one rule that matters for the runner: a case body must run in a subshell that sets `-e` itself and reports its status as a plain statement, because `if run_case; then` suspends `set -e` for the whole function and turns a failed assertion in the middle into a pass. ### Scope In scope: the case functions, the runner, and the fixture split. Explicitly not in scope: changing what any case asserts, and the other tests in `tests/`, which already have the shape.
vnprc closed this issue 2026-09-22 03:38:39 +01:00
Sign in to join this conversation.
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
allod/nexus#64
No description provided.