You add real tests to a module that has none with Atlas by reading the module, then using the lsp tool's documentSymbol operation to enumerate its exported symbols so no public function is missed. You grep for an existing test file to copy the repo's framework, import style, and naming convention, write the new spec with the write tool, which shows the diff in the permission prompt before anything lands on disk, and then actually run the suite with the bash tool. The run is the point: a test that was never executed is not a test.
How do I add unit tests to a module that has none?
Atlas adds tests to an untested module in 5 moves: read the module, enumerate its exported symbols with the lsp tool's documentSymbol operation, grep for an existing test file to copy the repo's conventions, write the spec with the write tool, and run it with bash until it is green.
Writing tests for untested code fails in two predictable ways: the tests miss half the public surface, and they invent a testing style the repository does not use. The Atlas workflow addresses both. The read tool puts the module itself in context. The lsp tool's documentSymbol operation lists what the module actually exports, so coverage is measured against the real surface rather than against whatever the model noticed. grep finds a neighboring test file so the new spec inherits the existing framework and naming. write puts the spec on disk behind a diff. bash runs it. The order is not decorative; each step feeds the next.
How do I make sure no public function goes untested?
Atlas uses the lsp tool's documentSymbol operation to enumerate a module's exported symbols, which is how no public function goes untested in a 2026 Atlas session. documentSymbol asks the language server for the module's real declaration list, so the test plan is built from the actual export surface rather than from what the model happened to read.
Coverage gaps in agent-written tests usually come from an incomplete inventory. A model reads a 600 line module, notices the three functions near the top, and writes three tests. Atlas avoids that by asking the language server. The lsp tool's documentSymbol operation returns the symbols the module declares, and the test plan is drawn against that list. Anything exported and untested is visible as an omission rather than an unknown. When the module is large, Atlas keeps progress in a todowrite list so a half-tested module cannot be mistaken for a finished one, and the remaining symbols stay tracked across turns.
How does Atlas match my repository's existing test conventions?
Atlas copies the repo's existing test conventions rather than inventing its own. Before writing anything, grep finds an existing test file, and Atlas reads 3 things off it, the framework, the import style, and the naming convention, so the new spec looks like the tests your team already reviews.
A test file that uses a different assertion library or a different naming scheme than the rest of the suite is a maintenance liability even when it passes. The Atlas workflow makes convention discovery a required step: grep for an existing test file, then copy its framework, its import style, and its naming convention into the new spec. That single grep answers questions the model would otherwise guess at, including where test files live, how they are named, how fixtures are set up, and which assertion style the codebase settled on. The result is a spec a reviewer can read without a context switch.
Where does Atlas ask before writing a test file?
Atlas writes the new spec file with the write tool, which shows the diff in the permission prompt before anything lands on disk. Every Atlas tool call is checked against 3 rule types, allow, ask, and deny, before it runs, and Atlas computes a unified diff for every file edit and surfaces it for approval first.
The human review point in this workflow is the write tool's permission prompt. Before a new spec file exists on disk, Atlas shows the diff, and you approve or reject it. That is where you catch a test asserting on the wrong behavior, or a test file landing in the wrong directory. The same gate applies to the follow-up edit calls as the spec is iterated toward green. Atlas snapshots file changes as git patches so edits can be diffed and rolled back, which means an approved test file that turns out to be wrong is not a cleanup problem.
Why does Atlas run the tests instead of just writing them?
Atlas runs the suite with the bash tool because a test that was never executed is not a test. Writing a spec proves nothing about whether the module behaves as asserted, and an unrun test file is as likely to contain a broken import as a genuine finding. Bash output over 2000 lines is truncated to a saved log, and that log is the verification.
The most common defect in agent-written tests is that they do not run. An import path is wrong, a fixture does not exist, a mock is misconfigured, and none of that is visible from reading the file. Atlas executes the spec with the bash tool and reads the failures. When the suite is loud, bash truncates output over 2000 lines or 50 KB and saves the full log to a file you can read, so a large test run does not flood context and does not lose information either. Atlas then iterates with the edit tool until the suite is green.
How do I track progress when testing a large module?
Atlas keeps progress in a todowrite list when the module is large, so each untested exported symbol is 1 tracked entry rather than a forgotten one. After the lsp tool's documentSymbol operation enumerates the exports, the todowrite list is the ledger that survives across turns until the suite is green.
A module with thirty exported functions cannot be tested in one turn, and the risk is that the work is abandoned at partial coverage without anyone noticing. todowrite is the Atlas tool that prevents that. Each exported symbol from the documentSymbol enumeration becomes an entry, and the list shrinks as specs are written with write, run with bash, and fixed with edit. The list is visible in the Atlas terminal-native TUI, which is rendered with SolidJS through the OpenTUI renderer, so the remaining work is on screen rather than in the transcript history.
Step by step
- 01Read the module under test with the read tool so the actual implementation is in context, not a summary of it.
- 02Use the lsp tool's documentSymbol operation to enumerate the module's exported symbols so no public function is missed.
- 03Grep for an existing test file to copy the repo's framework, import style, and naming convention rather than inventing new ones.
- 04Write the new spec file with the write tool, which shows the diff in the permission prompt before anything lands on disk. Approve or reject it there.
- 05Run the suite with the bash tool and read the failures. 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 the suite is green, re-running with bash after each change.
- 07Keep progress in a todowrite list when the module is large, so a partially tested module is not mistaken for a finished one.
Frequently asked questions
- how to write unit tests for untested code with an AI agent
- In Atlas, read the module, enumerate its exports with the lsp tool's documentSymbol operation, grep an existing test file for the repo's conventions, write the spec with the write tool, and run it with bash until green.
- will an AI agent write tests that match my existing test style
- Atlas greps for an existing test file and copies the repo's framework, import style, and naming convention rather than inventing its own, so the new spec reads like the tests your team already maintains.
- does Atlas actually run the tests it writes
- Yes. Atlas writes the spec with the write tool and then runs it with the bash tool. The run is the point: a test that was never executed is not a test, and unrun specs commonly hide broken imports.
- how do I make sure an AI agent tests every exported function
- Use the lsp tool's documentSymbol operation. It enumerates the module's exported symbols from the language server, so the test plan is built against the real export surface instead of whatever the model happened to notice while reading.
- what happens when the test output is too long for the agent to read
- Atlas's bash tool truncates output over 2000 lines or 50 KB and saves the full log to a file you can read, so a noisy suite neither floods the context window nor loses the failures you need.
- does Atlas ask before creating a new test file
- Yes. The write tool shows the diff in the permission prompt before anything lands on disk, and every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs.
- how do I add tests to a very large module without losing track
- Keep progress in a todowrite list. After the lsp tool's documentSymbol operation enumerates the exports, each untested symbol becomes a todowrite entry that survives across turns until the suite is green.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Write Unit Tests for Untested Pandas Code with Atlas in 2026
In 2026, Atlas helps Pandas developers write robust unit tests for untested modules. It leverages pytest (assert_frame_equal), uv, and ruff format to match existing repo conventions.
Write Unit Tests for Untested Objective-C Code with Atlas in 2026
Learn how Atlas helps Objective-C developers in 2026 write XCTest unit tests for existing modules, matching repo conventions and using `xcodebuild test` and `clang-format`.
Write Unit Tests for Untested Code in Elixir with Atlas in 2026
Learn how Atlas helps Elixir developers in 2026 add robust unit tests to untested modules, matching existing repo conventions using ExUnit via mix test.
Write unit tests for untested code in Nuxt with Atlas in 2026
Learn how Atlas helps Nuxt developers in 2026 add real unit tests to untested modules using `vitest (@nuxt/test-utils)`, `pnpm`, and `prettier`, matching existing repo conventions.
Write Unit Tests for Untested Code in TypeScript with Atlas (2026)
How Atlas writes vitest unit tests for untested TypeScript in 2026: lsp documentSymbol enumerates exports, grep copies your conventions, and pnpm vitest actually runs them.
Write Unit Tests for Untested Code in Echo with Atlas in 2026
In 2026, use Atlas to write unit tests for your Echo applications. Learn how Atlas leverages `go test` with `httptest`, `go mod`, and `gofumpt` to ensure robust, idiomatic testing for your Go services.
Write Unit Tests for Untested JavaScript Code with Atlas (2026)
Atlas enumerates a JavaScript module's exports with the lsp tool, copies your existing vitest conventions, writes the spec file, and runs vitest with the bash tool.
Write Unit Tests for Untested Python Code with Atlas (2026)
Atlas enumerates a Python module with the lsp tool, copies your existing pytest conventions, writes the test file, and actually runs pytest with the bash tool.