TestGen is a multi-language tool for inspecting code, generating tests, validating coverage, and fitting cleanly into terminal workflows, automation, and agent tooling. Start with analysis, preview dry-run artifacts, then write files only when you are ready.
TestGen stays high-level and predictable: one engine underneath, multiple ways to use it.
Use testgen tui when you want a guided, keyboard-friendly flow.
Use analyze, generate, and validate in scripts, local workflows, and CI.
Let coding agents inspect dry-run JSON and patch artifacts before writing tests.
Run testgen mcp when your client prefers tool calls over shell execution.
Keep wrappers thin. Keep orchestration in TestGen. Use the same review-first JSON contract across tools.
Use the repo-local skill and keep TestGen as the source of truth for scanning, generation, and validation.
Ship the repo-local command so Claude can review structured dry-run artifacts before materializing tests.
Use the command wrapper or connect through MCP when your setup prefers tool calling.
Expose testgen_generate, testgen_analyze, and testgen_validate over stdio.
TestGen currently supports JavaScript/TypeScript, Python, Go, Rust, and Java.
Jest, Vitest
pytest
testing, testify
cargo test
The clearest workflow is also the safest one. Analyze the codebase, generate dry-run output, inspect the structured results, then write files with validation only when the output looks right.
testgen analyze to inspect scope and estimate cost--dry-run --emit-patch --output-format json--validate when you want files writtencurl -fsSL https://raw.githubusercontent.com/princepal9120/testgen/main/install.sh | bash
./scripts/install-agent-integrations.sh /path/to/repo copy
testgen mcp
The website stays high level. The docs explain which source to read for which job.
Use docs.html as the high-level guide to installation, workflow, and doc ownership.
The current sources of truth live in the repo README, CLI reference, integrations docs, and architecture docs.
Older PRD and tech-spec documents are preserved for context, not for day-to-day implementation truth.
Contributors get a cleaner split between onboarding, references, architecture, integrations, and maintenance docs.