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
ininternal/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.