|
| 1 | +# RFC: Model Matrix Test Harness |
| 2 | + |
| 3 | +**Author:** George (gweale) **Date:** 2026-02-25 **Status:** Draft |
| 4 | + |
| 5 | +## Summary |
| 6 | + |
| 7 | +This RFC proposes a YAML-driven model matrix test harness that runs ADK conformance scenarios across multiple backend/model combinations (Gemini API, Vertex AI) and produces structured pass/fail reports. No existing ADK source code is modified. |
| 8 | + |
| 9 | +## Motivation |
| 10 | + |
| 11 | +ADK supports multiple backends and models, but there is no automated way to validate that the full feature surface — tool calling, auth flows, streaming, session rewind, MCP integration, third-party adapters, and the public API contract — works consistently across each backend/model pair. Manual testing is slow and coverage gaps are invisible. A matrix harness would catch backend-specific regressions before they reach users and provide a repeatable conformance baseline for new model releases. |
| 12 | + |
| 13 | +## Proposal |
| 14 | + |
| 15 | +This RFC proposes a standalone test harness that lives entirely in the `tests/` tree. A YAML configuration file declares targets (backend + environment), models, and a list of scenario IDs to execute. An orchestrator loads this config into a validated Pydantic schema, expands it into row plans (one per target/model pair), and runs each row's scenarios against a subprocess ADK API server, collecting results into a structured JSON report with a Markdown summary. |
| 16 | + |
| 17 | +Proposed entry point: |
| 18 | + |
| 19 | +```python |
| 20 | +def run_matrix( |
| 21 | + *, |
| 22 | + config_path: Path, |
| 23 | + output_dir: Optional[Path] = None, |
| 24 | + environment: Optional[Mapping[str, str]] = None, |
| 25 | + dry_run_override: Optional[bool] = None, |
| 26 | + strict_mode_override: Optional[bool] = None, |
| 27 | +) -> MatrixReport |
| 28 | +``` |
| 29 | + |
| 30 | +Key design elements: |
| 31 | + |
| 32 | +- **Config schema** — Pydantic models for targets, models, run options, and unit-test groups, with validation for required env vars and cross-references |
| 33 | +- **Extensible scenario registry** — ships with 25 scenarios across 9 domains (tool pipeline, MCP, auth, live/streaming, deployment parity, memory/rewind, third-party adapters, API contract, CLI flags). Adding a new scenario requires only writing a validator function, registering it as a `ScenarioDefinition`, and listing its ID in the YAML config — no orchestrator or schema changes needed |
| 34 | +- **Server runtime** — spins up a subprocess `adk api_server` per row, polls for readiness, and tears down after execution |
| 35 | +- **Live scenario runtime** — async client supporting `/run`, `/run_sse`, `/run_live` (WebSocket), concurrent prompt races, session rewind, and artifact operations |
| 36 | +- **Strict mode gate** — optionally enforces zero fail/error rows and flags unexpected skips |
| 37 | +- **Unit group integration** — runs named pytest selector groups as part of each row, reported alongside scenarios |
| 38 | + |
| 39 | +The architecture is designed so that the orchestrator, config schema, and reporting layer never need to change when new scenarios are added. Targets, models, and unit groups are also open for extension via the YAML config alone. Fully backward compatible — all code lives under `tests/`, no existing source files are modified. |
| 40 | + |
| 41 | +## Timeline |
| 42 | + |
| 43 | +N/A |
| 44 | + |
| 45 | +## Cross-workstream Impacts |
| 46 | + |
| 47 | +None — the harness consumes existing ADK public APIs and CLI commands without modifying them. |
| 48 | + |
| 49 | +## Outcome |
| 50 | + |
| 51 | +Success means any backend/model combination can be validated with a single `python run_matrix.py --config matrix.yaml` invocation, producing a structured report that CI or developers can use to catch regressions. Immediate next steps are enabling non-dry-run execution against live Gemini API and Vertex AI targets and integrating the harness into CI. |
0 commit comments