Skip to content

test: add missing httpapi coverage scenarios for 38 routes - #203

Merged
alltomatos merged 1 commit into
devfrom
claude/httpapi-coverage-187
Sep 12, 2026
Merged

alltomatos merged 1 commit into
devfrom
claude/httpapi-coverage-187

Conversation

@alltomatos

Copy link
Copy Markdown
Owner

Issue for this PR

Closes #187

Type of change

  • Bug fix
  • New feature
  • Refactor / code improvement
  • Documentation

What does this PR do?

bun run test:httpapi (three httpapi-exercise.ts modes: coverage/auth/effect, each run with --fail-on-missing --fail-on-skip) was failing because 38 routes had no exercise scenario, across the agentui, batuta, combo, mcp, memory, config (globalPath), experimental (background-job), external-agent, and telegram route groups. This made unit (linux)/unit (windows) CI report red even though every actual unit test passed, masking real signal.

Added a real scenario for each missing route, following the existing DSL conventions (http.protected.get/post/..., .seeded(...), .at(...), .json(...)/.jsonEffect(...), .mutating()). Added seedPost/rawRequest helpers (backend.ts, runner.ts, types.ts) so seed steps can create AgentUI/Batuta/Combo config-overlay state through the real in-process HTTP route rather than poking a service directly — those services only live behind the full HttpApiApp, not the plain AppLayer the other seed helpers run against.

Batuta scenarios were written to respect this repo's documented module invariants (CLAUDE.md): detection/skill-install always target the connected server, never the desktop client; detection never spawns which/where subprocesses; combobox-enablement is gated on skill-installed state separately from raw detection status.

Also found and fixed one bug introduced by the new combo.resolve scenario itself: it needed .withLlm() to register the fake test/test-model provider — without it, Combo.resolve correctly returned ComboExhaustedError since no provider/model could resolve. Fixed by adding .withLlm(), verified in isolation with --include combo.resolve.

Note: effect mode has 6 pre-existing failures unrelated to this change — pty.create, worktree.reset, v2.pty.create, session.prompt, session.prompt_async, session.command. Confirmed present before any of this PR's scenarios were added (stashed this PR's diff and reran — same failures, same error messages: PTY spawn 500s, a worktree-not-found 400, and fake-LLM text/timeout mismatches). Out of scope for #187 (which is specifically about missing scenarios, not these pre-existing broken ones) — worth tracking as a separate issue.

How did you verify your code works?

  • bun run script/httpapi-exercise.ts --mode coverage --fail-on-missing --fail-on-skip → 245 pass, 0 fail, 0 missing
  • bun run script/httpapi-exercise.ts --mode auth --fail-on-missing --fail-on-skip → 245 pass, 0 fail, 0 missing
  • bun run script/httpapi-exercise.ts --mode effect --fail-on-missing --fail-on-skip → 239 pass, 6 fail (all pre-existing, unrelated — see above), 0 missing
  • bun turbo typecheck → all 30 packages pass (also ran automatically on push via hook)

Screenshots / recordings

N/A (test-only change, no UI impact).

Checklist

  • I have tested my changes locally
  • I have not included unrelated changes in this PR

🤖 Generated with Claude Code

Closes #187

Adds exercise scenarios for the 38 routes that had none, across
agentui, batuta, combo, mcp, memory, config, experimental
(background-job), external-agent, and telegram route groups —
`bun run test:httpapi` was failing on `--fail-on-missing` even though
every real unit test passed, masking actual signal on unit (linux)/
unit (windows) CI.

Adds `seedPost`/`rawRequest` helpers (backend.ts, runner.ts, types.ts)
so seed steps can create AgentUI/Batuta/Combo config-overlay state
through the real in-process HTTP route rather than poking a service
directly — those services live only behind the full HttpApiApp, not
the plain AppLayer the other seed helpers run against.

Batuta scenarios were written to respect this repo's documented
module invariants (CLAUDE.md): detection/skill-install always target
the connected server never the desktop client, detection never spawns
`which`/`where` subprocesses, and combobox-enablement is gated on
skill-installed state separately from raw detection status.

Verified: all three exercise modes (coverage/auth/effect) report
missing=0. Coverage and auth modes are fully green (245 pass, 0 fail).
Effect mode has 6 pre-existing failures unrelated to this change
(pty.create, worktree.reset, v2.pty.create, session.prompt,
session.prompt_async, session.command — confirmed present before this
PR's scenarios were added, caused by unrelated LLM/PTY backend issues
in effect mode) — out of scope here and worth tracking separately.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

test: 38 httpapi routes missing coverage scenarios (test:httpapi)

1 participant