Why We Rewrote Our Python CLI in Go (and What We Gained)

#go #python #cli #devtools

TestSmith v1 was a Python CLI. It worked. Users could pip install testsmith, point it at a source file, and get a test scaffold back. But every team that tried to wire it into CI hit the same wall: Python environments.

The problem wasn't Python itself — it was distribution. A static analysis tool that requires a matching Python version, a virtual environment, and a pinned dependency tree is a hard sell for a step that runs on every push. We were shipping a tool, not a library. Tools should be frictionless.

The Decision

We rewrote TestSmith v2 in Go. The goal was a single static binary with no runtime dependencies — something you could drop into any CI runner, any Docker image, any developer's PATH, and it would just work.

Go was the right choice for three reasons:

Single binary. go build produces one self-contained executable. No pip, no venv, no requirements.txt. Users download a binary or brew install it and they're done.

Cross-platform with one build. The v1 CI matrix was a headache — different Python versions across Ubuntu, macOS, and Windows, with slightly different behavior on each. Go's cross-compilation gave us linux/amd64, darwin/amd64, darwin/arm64, and windows/amd64 from a single build step.

Native concurrency. Test generation is embarrassingly parallel — each file is independent. Go's goroutines and channels made the fan-out generation and the debounced file watcher straightforward to implement without pulling in async libraries.

What Changed

The command surface was cleaned up in the same pass. v1 used flags for everything:

testsmith <file>         # generate
testsmith --all          # generate all
testsmith --graph        # dependency graph
testsmith --prune        # prune stale fixtures
testsmith --watch        # watch mode

v2 uses proper subcommands:

testsmith generate <file>
testsmith generate --all
testsmith graph
testsmith prune
testsmith watch

This made shell completion, help text, and per-command flags much cleaner. Cobra's built-in completion generator gives us bash, zsh, fish, and PowerShell completion for free.

Architecture Change

v1 was monolithic Python — one codebase with hardcoded branches for each language it supported. Adding a new language meant editing multiple core files.

v2 uses a LanguageDriver interface. Each language (Go, Python, TypeScript, Java, C#) is a separate package that implements the interface. The core generation pipeline never knows which language it's dealing with — it just calls through the interface:

type LanguageDriver interface {
    DetectProject(dir string) (*ProjectContext, error)
    AnalyzeFile(path string, ctx *ProjectContext) (*SourceAnalysis, error)
    DeriveTestPath(sourcePath string, ctx *ProjectContext) (string, error)
    GenerateTestFile(analysis *SourceAnalysis, opts GenerateOpts) (*GeneratedFile, error)
    // ... and more
}

Adding a new language is now a matter of creating a new package and registering it — no changes to the pipeline.

What We Kept

The v1 Python package didn't disappear. It lives in archive/v1/ and continues to receive bug fixes during the transition period. Teams already using v1 in production don't need to migrate immediately. The v2 binary is a clean break for new users; v1 stays stable for existing ones.

Was It Worth It?

Yes, unambiguously. The CI story went from "install Python, set up venv, pin deps" to "download one binary." The Windows test matrix went from flaky (Python path issues) to clean. And the plugin architecture means we can add a Ruby or Rust driver without touching the core generation logic.

The rewrite took longer than a feature would have. But distribution friction is a silent project killer — nobody files a bug for "this was annoying to set up," they just stop using the tool.

TestSmith is an open-source CLI for generating test scaffolds across Go, Python, TypeScript, Java, and C#. The source is at github.com/orieken/testsmith.

DEV Community