Atlas writes unit tests for untested Go code by copying your repository's conventions rather than inventing its own. Atlas reads the target package, enumerates its exported symbols with the lsp tool's documentSymbol operation so no public function is missed, greps for an existing _test.go file to copy the table-driven style your module already uses, writes the new spec with the write tool, and then actually runs go test. The run is the point: a test that was never executed is not a test, and go test is the only thing that settles it.
How do you add unit tests to an untested Go package?
Atlas adds unit tests to an untested Go package in 5 moves: read the package, enumerate exported symbols with the lsp tool's documentSymbol operation, grep an existing _test.go for conventions, write the new file with the write tool, then run go test through bash until it is green.
The job is to add real tests for a module that has none, matching the conventions the repo already uses. Go makes both halves tractable. Exported identifiers are capitalized, so the public surface of a package is unambiguous, and test files are just _test.go files in the same package with func TestXxx(t *testing.T) signatures. Atlas tools this workflow uses are read, lsp, grep, write, bash, edit, and todowrite. Atlas indexes code by AST declarations using tree-sitter, not blind line windows, so a Go function or method is retrieved as a whole declaration with its receiver and signature intact.
How does Atlas find every exported Go function that needs a test?
Atlas uses the lsp tool's documentSymbol operation to enumerate a Go file's exported symbols, so no public function is missed. A package with 14 exported functions and 3 methods on a struct produces a complete list, rather than the 4 obvious ones a model would notice by skimming.
Coverage gaps come from omission, not from difficulty. Reading a Go file top to bottom and writing tests for what stands out reliably misses the small exported helper at the bottom that everything depends on. documentSymbol returns the declared symbols in the file, so Atlas has an explicit checklist: every capitalized func, every method with a receiver, every exported type with behavior worth asserting. Atlas reads the package source alongside that list so the tests assert real behavior rather than restating the signature. When the package is large, Atlas keeps progress in a todowrite list so the second half of the symbol list does not get lost when the first half turns green.
How does Atlas match the existing test style in a Go repo?
Atlas greps for an existing _test.go file to copy the repo's framework, import style, and naming convention. In a Go module that usually reveals a table-driven test with 3 ingredients: a slice of case structs, a range loop, and t.Run(tc.name, ...) reporting mismatches with t.Errorf.
Convention matching is not politeness, it is reviewability. A Go repo that writes table-driven tests everywhere and then receives a hand-rolled sequence of if statements has gained a test and a style argument. Atlas greps for a neighboring _test.go, reads how it declares its cases, whether it uses the standard testing package alone or a helper library the go.mod already requires, and whether it uses t.Fatalf or t.Errorf. The new file copies that. Atlas's grep takes a real regex plus include and path filters and runs through ripgrep, so scoping to *_test.go finds the conventions fast even in a module with hundreds of packages.
How does Atlas write a new Go test file safely?
Atlas writes the new Go spec file with the write tool, which shows the diff in the permission prompt before anything lands on disk. A new parser_test.go beside parser.go is 1 approval away, because every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs.
Writing a Go test file is a new-file write, and Atlas gates it like any other. The file lands beside the code as package_test.go convention dictates, in the same package when the tests need access to unexported identifiers, or in the _test external package when the point is to exercise the public API only. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so the table of test cases, the t.Run names, and the assertions are all reviewed before the file exists. Run gofmt on the new file so it matches the module and gofmt -l stays quiet in CI.
Why does Atlas run go test instead of just writing tests?
Atlas runs the suite with the bash tool because a test that was never executed is not a test. go test ./... against a new _test.go file catches 3 things no diff can show: the compile error, the nil pointer in the fixture, and the assertion that passes for the wrong reason.
Running is where generated Go tests earn their keep or die. The common failures are boring and immediate: an unused import that Go rejects at compile time, a struct literal missing a field, a t.Errorf format string with the wrong verb. go test surfaces all of them in seconds. Output over 2000 lines or 50 KB is truncated by the bash tool, and the full log is saved to a file you can read, so a big Go module's test output stays fully available rather than being cut to a tail. Atlas reads the failures and iterates with the edit tool until go test is green.
How do you keep track of testing a large Go package?
Atlas keeps progress in a todowrite list when the Go module is large, one entry per exported symbol still lacking a test. A package with 17 exported functions is not a single edit, and a todowrite list means the 9 that are still untested survive into the next turn instead of being forgotten.
Long testing sessions lose their thread without external state. The todowrite list holds it: each pending item names an exported Go function, and items close as go test proves the new table-driven cases pass. Atlas iterates with edit between runs, re-running only the affected package with go test on that path rather than the whole module every time. When the work is done, Atlas reads git branches, status, and diffs, and can stage and create commits on your behalf, so the new _test.go files land as one reviewable commit. Atlas snapshots file changes as git patches so edits can be diffed and rolled back.
Step by step
- 01Run atlas in a Go module with a go.mod and let Atlas read your packages, interfaces, and go.sum dependencies.
- 02Read the module under test, then use the lsp tool's documentSymbol operation to enumerate its exported symbols so no public function is missed.
- 03Grep for an existing _test.go file to copy the repo's framework, import style, and naming convention; scoping the grep to *_test.go finds the table-driven idiom fast.
- 04Write the new spec file with the write tool, for example parser_test.go beside parser.go, which shows the diff in the permission prompt before anything lands on disk.
- 05Run the suite with the bash tool using go test on the affected package; output over 2000 lines or 50 KB is truncated and the full log is saved to a file you can read.
- 06Iterate with the edit tool until go test is green, fixing compile errors, missing struct fields, and assertions that pass for the wrong reason.
- 07Keep progress in a todowrite list when the package is large, one entry per exported symbol still lacking a test.
- 08Run gofmt on the new _test.go files so they match the module and gofmt -l stays quiet in CI, then review the diff before committing.
Frequently asked questions
- how do I write unit tests for an untested go package
- Enumerate the exported symbols first with the lsp tool's documentSymbol operation so no public function is missed, grep an existing _test.go for the repo's table-driven convention, write the new file with Atlas's write tool, then run go test to prove it. Atlas does exactly that sequence.
- can an AI agent write table-driven tests in go
- Yes, and Atlas copies the convention rather than inventing one. Atlas greps a neighboring _test.go to see whether the module uses a slice of case structs with t.Run and t.Errorf, then matches that style in the new file so reviewers see familiar code.
- how do I make sure an AI agent tests every exported function
- Use the lsp tool's documentSymbol operation, which returns the declared symbols in the file. Atlas uses that as an explicit checklist of capitalized funcs, methods with receivers, and exported types, so coverage gaps from omission do not happen.
- does an AI coding agent actually run go test or just write tests
- Atlas runs go test through its bash tool, because a test that was never executed is not a test. The run catches unused imports, missing struct literal fields, and assertions that pass for the wrong reason, none of which are visible in a diff.
- where should go test files live in a module
- Beside the code as a _test.go file, in the same package when the tests need unexported identifiers and in the external _test package when the point is to exercise only the public API. Atlas reads your go.mod and package layout before choosing.
- what happens when go test output is too long for an AI agent to read
- Atlas's bash tool truncates output at 2000 lines or 50 KB, writes the complete log to a retained file, and tells you the path, so a large Go module's failures are read from the full log rather than from a lossy tail.
- how do I keep an AI agent on track while testing a big go package
- Have it keep a todowrite list, one entry per exported symbol still lacking a test. Atlas closes items as go test proves each new set of table-driven cases, so the untested half of a seventeen-function package survives into the next turn.
- should I run gofmt on AI generated go tests
- Yes. Run gofmt on the new _test.go files so they match the rest of the module and gofmt -l stays quiet in CI. Atlas can run gofmt through the bash tool in the same session that wrote the tests.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Write Unit Tests for Untested Code with Atlas in 2026
How to write unit tests for untested code with Atlas in 2026: the lsp tool enumerates exported symbols, grep copies repo conventions, and bash actually runs the suite.
Atlas for Go in 2026
Atlas, the terminal-native AI coding agent, empowers Go developers in 2026 with intelligent code understanding, safe refactoring, and robust testing capabilities.
Self-Review Your Working Diff Before Committing in Go with Atlas (2026)
Atlas self-reviews an uncommitted Go diff: bash produces the patch, read checks each package in full, grep hunts debug leftovers, and session revert restores a snapshot.
Run Atlas Headless in CI for Go Developers in 2026
Automate Go code changes with Atlas in your CI pipeline. Learn how to run Atlas headless, get machine-readable JSON output, and integrate with go test and go mod in 2026.
Refactor a Legacy Module in Go With Atlas (2026 Guide)
How to refactor a legacy Go module with Atlas in 2026: lsp findReferences enumerates callers, apply_patch anchors on context, and go test proves behavior after each hunk.
Run the test suite and triage the failures in Go with Atlas (2026)
Triage a wall of red go test output with Atlas in 2026: bash truncates at 2000 lines or 50 KB, saves the full log, and turns distinct root causes into a todowrite list.
Research a Third-Party API Before Integrating It in Go with Atlas (2026)
Atlas fetches live API docs before you write Go: websearch finds the page, webfetch pulls it behind a permission prompt, and your struct tags match reality in 2026.
Trace a runtime bug from a stack trace in Go with Atlas (2026)
Go from a Go panic stack trace to the responsible line in 2026 with Atlas: read each frame at its offset, grep the error string, and walk callers with lsp findReferences.