Language-Agnostic Code Generation: The Driver Plugin Model

The article describes TestSmith's language-agnostic code generation system, which uses a plugin-based "Driver Plugin Model" to support five programming languages (Go, Python, TypeScript, Java, and C#). Each language implements a single `LanguageDriver` interface that handles project detection, file analysis, test generation, and framework configuration, allowing the generation pipeline and CLI commands to work without importing any specific driver package. The system also uses a `TestAdapter` interface to handle multiple test frameworks within each language, such as Jest and Mocha for TypeScript or JUnit 4 and JUnit 5 for Java.

TestSmith generates test scaffolds for five languages: Go, Python, TypeScript, Java, and C . Each language has its own project structure conventions, test frameworks, import styles, and code patterns. The naive implementation would be a big switch statement throughout the codebase. We chose a plugin model instead. The Problem with Hardcoded Branches When a codebase switches on language in multiple places, every new language requires touching every branch point. Miss one and you get a silent bug — the new language falls through to some default behavior that doesn't apply to it. This is the classic Open-Closed violation: you have to modify existing code to extend it. The LanguageDriver Interface Every language in TestSmith implements a single interface: type LanguageDriver interface { // Detection DetectProject dir string ProjectContext, error FileExtensions string // Analysis AnalyzeFile path string, ctx ProjectContext SourceAnalysis, error ClassifyDependency dep ImportInfo, ctx ProjectContext DependencyCategory DeriveTestPath sourcePath string, ctx ProjectContext string, error DeriveModulePath sourcePath string, ctx ProjectContext string, error // Generation GenerateTestFile analysis SourceAnalysis, opts GenerateOpts GeneratedFile, error GenerateFixture dep string, analysis SourceAnalysis, opts GenerateOpts GeneratedFile, error GenerateBootstrap plan GenerationPlan, ctx ProjectContext GeneratedFile, error // Framework config GetTestFrameworkConfig TestFrameworkConfig SelectAdapter ctx ProjectContext TestAdapter // LLM integration LLMContext ctx ProjectContext map string string LLMVocabulary map string string // Migration and validation ListMigrators Migrator ValidateFile path string, ctx ProjectContext ValidationIssue, error } The generation pipeline, the CLI commands, and the watch mode all work against this interface. They never import a specific driver package. How Detection Works When you run testsmith generate , the first step is figuring out what language you're in. The registry tries each registered driver in turn: func Detect dir string domain.LanguageDriver, error { for , d := range drivers { ctx, err := d.DetectProject dir if err == nil && ctx = nil { return d, nil } } return nil, domain.ErrProjectNotFound } Each driver's DetectProject walks upward from the starting directory looking for its own project markers — go.mod for Go, pyproject.toml or setup.py for Python, package.json for TypeScript, pom.xml or build.gradle for Java, .csproj or .sln for C . One subtle requirement: a driver must not claim an ancestor project that belongs to a different language. If you run TestSmith from inside an example project that lives inside a Go repo, the Python driver shouldn't walk up past the Go project's .git boundary and claim the repo root. We solve this by checking VCS stop markers .git , .hg , .svn at ancestor directories only — not at the starting directory itself, since a legitimate project root can have both a project marker and a .git directory. func findRoot startDir string string, error { dir := startDir for { // At ancestor dirs, stop at VCS boundaries first. if dir = startDir { for , stop := range stopMarkers { if , err := os.Stat filepath.Join dir, stop ; err == nil { return "", domain.ErrProjectNotFound } } } // Then check for project markers. for , marker := range rootMarkers { if , err := os.Stat filepath.Join dir, marker ; err == nil { return dir, nil } } parent := filepath.Dir dir if parent == dir { break } dir = parent } return "", domain.ErrProjectNotFound } The Adapter Layer Within a language, there can be multiple test frameworks. TypeScript has Jest, Vitest, and Mocha. Java has JUnit 4, JUnit 5, TestNG, and Spring Boot Test. Each framework has its own import style, mock library, assertion syntax, and file naming conventions. We model this with a TestAdapter interface: type TestAdapter interface { Name string FileNamingConvention FileNaming ImportStyle ImportStyle MockLibrary string AssertionStyle string LLMVocabulary map string string } Each driver has a registry of adapters and a SelectAdapter method that reads the project config or sniffs package.json devDependencies, pom.xml dependencies, etc. to pick the right one. The LLM prompt gets the vocabulary from the selected adapter — so the model knows to generate expect x .toBe y for Jest but assert.Equal t, x, y for Go's testify. Adding a New Language Because everything flows through the interface, adding a new language driver is isolated: - Create a new package under internal/drivers/<lang / - Implement domain.LanguageDriver — the compiler tells you exactly what's missing - Register it in internal/registry/registry.go - Optionally add a Verifier in internal/generation/verify.go for post-write compile checking No other files change. The existing drivers are untouched. The pipeline, CLI, and watch mode pick it up automatically. The Dependency Direction The plugin model enforces a strict dependency direction: cmd → generation → domain ← drivers ← llm domain defines the interfaces. drivers implement them. generation uses them via the interface. Neither generation nor drivers imports the other. This is the Dependency Inversion Principle applied at the package level — and it's enforced by Go's import cycle detector. When you add a new driver, it's impossible to accidentally reach into the generation pipeline or the LLM layer — Go won't compile it. The architecture is self-enforcing. Next in this series: making LLM calls reliable when you're hitting them for every public member of every source file.