{"slug": "language-agnostic-code-generation-the-driver-plugin-model", "title": "Language-Agnostic Code Generation: The Driver Plugin Model", "summary": "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.", "body_md": "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`\n\nstatement throughout the codebase. We chose a plugin model instead.\n\n## The Problem with Hardcoded Branches\n\nWhen 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.\n\n## The LanguageDriver Interface\n\nEvery language in TestSmith implements a single interface:\n\n```\ntype LanguageDriver interface {\n    // Detection\n    DetectProject(dir string) (*ProjectContext, error)\n    FileExtensions() []string\n\n    // Analysis\n    AnalyzeFile(path string, ctx *ProjectContext) (*SourceAnalysis, error)\n    ClassifyDependency(dep ImportInfo, ctx *ProjectContext) DependencyCategory\n    DeriveTestPath(sourcePath string, ctx *ProjectContext) (string, error)\n    DeriveModulePath(sourcePath string, ctx *ProjectContext) (string, error)\n\n    // Generation\n    GenerateTestFile(analysis *SourceAnalysis, opts GenerateOpts) (*GeneratedFile, error)\n    GenerateFixture(dep string, analysis *SourceAnalysis, opts GenerateOpts) (*GeneratedFile, error)\n    GenerateBootstrap(plan *GenerationPlan, ctx *ProjectContext) (*GeneratedFile, error)\n\n    // Framework config\n    GetTestFrameworkConfig() TestFrameworkConfig\n    SelectAdapter(ctx *ProjectContext) TestAdapter\n\n    // LLM integration\n    LLMContext(ctx *ProjectContext) map[string]string\n    LLMVocabulary() map[string]string\n\n    // Migration and validation\n    ListMigrators() []Migrator\n    ValidateFile(path string, ctx *ProjectContext) ([]ValidationIssue, error)\n}\n```\n\nThe generation pipeline, the CLI commands, and the watch mode all work against this interface. They never import a specific driver package.\n\n## How Detection Works\n\nWhen you run `testsmith generate`\n\n, the first step is figuring out what language you're in. The registry tries each registered driver in turn:\n\n```\nfunc Detect(dir string) (domain.LanguageDriver, error) {\n    for _, d := range drivers {\n        ctx, err := d.DetectProject(dir)\n        if err == nil && ctx != nil {\n            return d, nil\n        }\n    }\n    return nil, domain.ErrProjectNotFound\n}\n```\n\nEach driver's `DetectProject`\n\nwalks upward from the starting directory looking for its own project markers — `go.mod`\n\nfor Go, `pyproject.toml`\n\nor `setup.py`\n\nfor Python, `package.json`\n\nfor TypeScript, `pom.xml`\n\nor `build.gradle`\n\nfor Java, `.csproj`\n\nor `.sln`\n\nfor C#.\n\nOne 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`\n\nboundary and claim the repo root. We solve this by checking VCS stop markers (`.git`\n\n, `.hg`\n\n, `.svn`\n\n) at ancestor directories only — not at the starting directory itself, since a legitimate project root can have both a project marker and a `.git`\n\ndirectory.\n\n```\nfunc findRoot(startDir string) (string, error) {\n    dir := startDir\n    for {\n        // At ancestor dirs, stop at VCS boundaries first.\n        if dir != startDir {\n            for _, stop := range stopMarkers {\n                if _, err := os.Stat(filepath.Join(dir, stop)); err == nil {\n                    return \"\", domain.ErrProjectNotFound\n                }\n            }\n        }\n        // Then check for project markers.\n        for _, marker := range rootMarkers {\n            if _, err := os.Stat(filepath.Join(dir, marker)); err == nil {\n                return dir, nil\n            }\n        }\n        parent := filepath.Dir(dir)\n        if parent == dir {\n            break\n        }\n        dir = parent\n    }\n    return \"\", domain.ErrProjectNotFound\n}\n```\n\n## The Adapter Layer\n\nWithin 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.\n\nWe model this with a `TestAdapter`\n\ninterface:\n\n```\ntype TestAdapter interface {\n    Name() string\n    FileNamingConvention() FileNaming\n    ImportStyle() ImportStyle\n    MockLibrary() string\n    AssertionStyle() string\n    LLMVocabulary() map[string]string\n}\n```\n\nEach driver has a registry of adapters and a `SelectAdapter`\n\nmethod that reads the project config (or sniffs `package.json`\n\ndevDependencies, `pom.xml`\n\ndependencies, 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)`\n\nfor Jest but `assert.Equal(t, x, y)`\n\nfor Go's testify.\n\n## Adding a New Language\n\nBecause everything flows through the interface, adding a new language driver is isolated:\n\n- Create a new package under\n`internal/drivers/<lang>/`\n\n- Implement\n`domain.LanguageDriver`\n\n— the compiler tells you exactly what's missing - Register it in\n`internal/registry/registry.go`\n\n- Optionally add a\n`Verifier`\n\nin`internal/generation/verify.go`\n\nfor post-write compile checking\n\nNo other files change. The existing drivers are untouched. The pipeline, CLI, and watch mode pick it up automatically.\n\n## The Dependency Direction\n\nThe plugin model enforces a strict dependency direction:\n\n```\ncmd → generation → domain ← drivers\n                           ← llm\n```\n\n`domain`\n\ndefines the interfaces. `drivers`\n\nimplement them. `generation`\n\nuses them via the interface. Neither `generation`\n\nnor `drivers`\n\nimports the other. This is the Dependency Inversion Principle applied at the package level — and it's enforced by Go's import cycle detector.\n\nWhen 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.\n\n*Next in this series: making LLM calls reliable when you're hitting them for every public member of every source file.*", "url": "https://wpnews.pro/news/language-agnostic-code-generation-the-driver-plugin-model", "canonical_source": "https://dev.to/orieken/language-agnostic-code-generation-the-driver-plugin-model-2ip0", "published_at": "2026-05-23 16:29:11+00:00", "updated_at": "2026-05-23 17:05:12.656835+00:00", "lang": "en", "topics": ["developer-tools", "open-source"], "entities": ["TestSmith"], "alternates": {"html": "https://wpnews.pro/news/language-agnostic-code-generation-the-driver-plugin-model", "markdown": "https://wpnews.pro/news/language-agnostic-code-generation-the-driver-plugin-model.md", "text": "https://wpnews.pro/news/language-agnostic-code-generation-the-driver-plugin-model.txt", "jsonld": "https://wpnews.pro/news/language-agnostic-code-generation-the-driver-plugin-model.jsonld"}}