Product Roadmap¶
Where Testosterone (testo-core, CLI testo) stands today and what comes next. Open engineering debt lives in Technical Debt Tracker; the per-phase release checklists from the original plan are in the Archive.
Where it is now¶
One engine behind every surface. testosterone.yaml → CycleRunService → engine.run_plan() → framework adapters → reporting and persistence. The CLI, the FastAPI backend and the CI wrappers all start runs this way; the Docker-based second execution stack and its uqo run --config contract were removed after 1.0.0. See Architecture Overview.
| Area | State |
|---|---|
| Frameworks | pytest, behave, behavex, plus command for any other runner with JUnit XML import (Command Adapter and JUnit Import) |
| CLI | testo run (Rich, --stream, --ci NDJSON), reports, diff/summary, config, doctor/clean/watch/init; exit codes 0–4 (Command Reference) |
| Storage | SQLite by default, PostgreSQL/MySQL through the repository layer (Repository Pattern). Docker and MinIO are not required |
| UI | React + Vite + Tailwind frontend on the FastAPI /api/v1 API; frontend types generated from the OpenAPI schema (Phase 5 UI Redesign). The Streamlit prototype was removed |
| Analytics | Dashboard, run-to-run delta with per-stage and per-test changes (Delta Comparison Policy), test pyramid, flaky test detection (Open Source Features) |
| AI | Bring-your-own-key failure summaries (Phase 4 BYOK and Failure Analysis) |
| CI | GitHub Action and GitLab template wrapping testo run --ci (CI-CD Pipeline Setup) |
| Demo | A Pages pipeline runs testosterone on itself and on the deliberately broken fake-api app, then publishes the React UI as a read-only snapshot (GitLab Pages Demo) |
| Distribution | Version 1.1.0 is cut (pyproject.toml, CHANGELOG.md) but not yet tagged or published; a GitHub Release publishes to PyPI (testo-core), GHCR (testo-runner) and, when configured, JFrog Artifactory (Publishing to PyPI § Current state) |
Next¶
- Release v1.1.0. Tag
v1.0.0andv1.1.0, movev1, and create the GitHub Release. - Repo allow-list for the API.
testo-apibinds127.0.0.1and can requireTESTO_API_TOKENon mutating requests; before it runs anywhere shared it also needs an allow-list of target repos. - Parallel stages. Stages run sequentially; only BehaveX parallelizes internally. Opt-in parallel stages need isolated per-stage artifact trees and aggregated exit classification.
- Concurrent run guard. Today the only guard is the API's in-memory check that rejects a second run of the same cycle with 409 (
testo_api/cycle_execution_manager.py). Two CLI runs of one cycle on one machine shareartifacts/<cycle>/and overwrite each other, and nothing stops a CI run and a local run from hitting the same deployment at once. Every run enters throughCycleRunService.run(), so a guard goes there, beforerun_plan, without a refactor. Three levels, smallest first: - A lock file per cycle under
artifacts/<cycle>/: a second run on the same machine exits3with a clear message. - A per-environment lease in the database (an
environment:key on the cycle, a row with an expiry): a second run against the same environment waits or fails. Only works across machines that share one database (e.g. Postgres), not per-machine SQLite. - A real run queue. That is a central service and not worth it yet.
- Smaller items (signal-aware exit codes, reporter failure policy): see Technical Debt Tracker.
How it got here¶
The project started as "UQO", a Docker-and-Streamlit platform, and was delivered in four phases: packaging and a database-agnostic repository layer; drop-in CI wrappers; the React UI, delta engine and unified dashboard; then BYOK AI failure analysis. Each phase had a release checklist; those checklists and the dated plans and audits behind them are kept in the Archive.