Skip to content

refactor(e2e): data-driven per-tool matrix (replaces scenario suite)#165

Open
tgarciai wants to merge 3 commits into
mainfrom
refactor/e2e-per-tool-matrix
Open

refactor(e2e): data-driven per-tool matrix (replaces scenario suite)#165
tgarciai wants to merge 3 commits into
mainfrom
refactor/e2e-per-tool-matrix

Conversation

@tgarciai

Copy link
Copy Markdown
Member

Replaces the 22 scenario-based E2E tests with a single data-driven per-tool matrix: one runner loads the tool catalog and exercises every registered tool (130 → ~387 cases).

Cases per tool (derived from catalog metadata)

Case Applies to Asserts
discovery all 130 tool registered + visible in session catalog
happy_path 110 (with example) invoke with the catalog's own example args
invalid_input 71 (required fields) empty args rejected, never executed
approval_gate 32 (requires_approval) invoking without approval is blocked
policy_traversal 44 (path_field) a workspace-escape path is denied

The three governance cases are the deterministic backbone (the runtime's core value — no governance bypass on any tool). happy_path is honest: real succeeded for the ~79 workspace-local tools on a seeded fixture, fail if a tool's own example is rejected by governance, executed (non-failing) when an external dependency is absent — so the suite is green on a bare cluster while still exercising real execution.

Changes

  • New e2e/tests/00-tool-matrix/test_tool_matrix.py, Dockerfile, job.yaml
  • Removed 22 scenario dirs (01–24)
  • Updated e2e_tests.yaml, e2e/README.md, chart e2e.tests values, and testing/helm-install/kubernetes-deploy docs

Net: +451 / −9260. helm lint passes. Local dry-run of the matrix (no cluster):
```
E2E_DRY_RUN=1 CATALOG_PATH=internal/adapters/tools/catalog_defaults.yaml python3 e2e/tests/00-tool-matrix/test_tool_matrix.py
```

🤖 Generated with Claude Code

tgarciai and others added 3 commits June 15, 2026 23:23
The end-to-end suite was 22 scenario tests (health, session, invoke, policy,
learning, agents…). Replace all of them with a single data-driven runner that
loads the tool catalog and exercises every registered tool (130 -> 387 cases).

Per tool, derived from catalog metadata:
- discovery         tool registered + visible in the session catalog
- happy_path        invoke with the catalog's own example args
- invalid_input     empty args must be rejected, never executed
- approval_gate     requires_approval tool invoked without approval -> blocked
- policy_traversal  path_field set to a workspace escape -> denied

The three governance cases assert hard for every applicable tool (the runtime's
core value). happy_path records real success for workspace-local tools, fails if
a tool's own example is rejected by governance, and is "executed" (non-failing)
when an external dependency is absent — green on a bare cluster, honest about
coverage. E2E_DRY_RUN=1 prints the matrix without a cluster.

- New: e2e/tests/00-tool-matrix (runner, Dockerfile, job.yaml)
- Removed: 22 scenario test dirs (01-24)
- Updated: e2e_tests.yaml, e2e/README, chart e2e.tests values, and the
  testing/helm-install/kubernetes-deploy docs

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The internal/e2e guard test still required the deleted specialist scenario
tests, and the unified e2e/Dockerfile still COPY'd the now-deleted per-test
scripts. Update both to the per-tool matrix runner (the unified image ships
test_tool_matrix.py + the catalog that drives it).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Validated by running the matrix against the live cluster (130 tools, 358
cases, 0 fail):

- print_step takes (step, description); the preamble/matrix/summary calls
  passed a single arg and crashed the run at startup.
- Tools gated by tool_profile/role (k8s rollout/saturation, notify,
  github.merge_pr, …) are correctly hidden from a generic session — record
  them as `gated` and skip their invocation cases instead of failing discovery.
- happy_path is best-effort: `pass` on succeeded, otherwise `executed` (role/
  policy restriction, missing external dep, or fixture state the example
  assumes). The hard governance guarantees are the dedicated invalid_input /
  approval_gate / policy_traversal cases, which held across the whole catalog.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@sonarqubecloud

Copy link
Copy Markdown

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.

1 participant