# Write Unit Tests for Untested Code in TypeScript with Atlas (2026) > Atlas enumerates a TypeScript module's exports with the lsp documentSymbol operation, copies your existing .test.ts conventions, and runs the new spec with vitest before calling it done. Atlas writes unit tests for untested TypeScript by reading the module, enumerating its exported symbols with the lsp tool's documentSymbol operation so no public function is missed, and copying the conventions your repo already uses instead of inventing new ones. Atlas greps for an existing .test.ts file to match the framework, import style, and naming pattern, writes the new spec with the write tool, which shows the diff in the permission prompt before anything lands on disk, and then actually runs it with vitest through bash. The run is the point: a test that was never executed is not a test. ## Key takeaways - The lsp tool's documentSymbol operation enumerates every export, so a TypeScript module's public surface is covered rather than sampled. - Atlas greps an existing .test.ts to copy your framework, import style, and tsconfig path-alias usage instead of inventing conventions. - The write tool shows the new spec as a diff in the permission prompt before anything lands on disk. - Atlas runs pnpm vitest itself; a test that was never executed is not a test. - Large modules get one todowrite entry per untested export, and prettier keeps the new spec consistent with the repo. ## How do you write unit tests for an untested TypeScript module? Atlas writes unit tests for an untested TypeScript module in 5 moves: read the module, enumerate every export with the lsp tool's documentSymbol operation, grep for an existing .test.ts to copy conventions, write the spec, then run vitest through bash. Step two is what stops a public function from being silently skipped. The usual failure of AI-written TypeScript tests is coverage theater: the model tests the two functions it happened to notice in the file it read, produces a confident summary, and leaves three exported helpers untested. Atlas closes that gap structurally. The lsp tool's documentSymbol operation returns the module's symbol table, so the exported functions, the exported class methods, and the exported types are enumerated from the language server rather than from a skim. When src/lib/pricing.ts exports calculateSubtotal, applyDiscount, and formatCurrency, all three end up in the spec, and any overload or default-exported factory shows up too. Atlas then reads the module body to understand what each export actually does before asserting on it, because the point is testing behavior, not restating the type signature that tsc already checks. ## How does Atlas match my repo's existing vitest conventions? Atlas greps for an existing test file before writing a new one, so the new spec copies 3 things from your repo: the framework, the import style, and the naming convention. In a TypeScript repo that also means matching how tsconfig path aliases are imported and whether specs live beside the source or under tests/. TypeScript repos are opinionated in ways that are invisible to a model that has not looked. Some import the subject with a tsconfig path alias like @/lib/pricing, others use a relative ../pricing, and getting it wrong means vitest cannot resolve the module at all. Some name files pricing.test.ts, others pricing.spec.ts, and a vitest include pattern will silently ignore the wrong one, producing a spec that never runs and a suite that stays green for the wrong reason. Some repos mock with vi.mock at the top of the file, others inject fakes through the constructor. Atlas greps an existing spec, reads it, and mirrors it. The result is a file that looks like the ones a human on the team wrote, which is the difference between a test that gets maintained and a test that gets deleted in the next cleanup pass. ## Does Atlas run the TypeScript tests it writes, or just write them? Atlas runs the tests it writes. After the write tool lands the new spec, Atlas invokes vitest through the bash tool and reads the failures. Output over 2000 lines or 50 KB is truncated and the complete log is saved to a file Atlas can read, so a noisy vitest run still gets triaged in full. A generated test that has never been executed is a liability, not an asset. It may not compile under your tsconfig strict settings. It may assert on a shape that does not match what the function returns, and the mismatch is invisible until CI catches it three commits later. Atlas therefore treats the vitest run as part of writing the test, not as an optional afterthought. The first run of a freshly written spec commonly fails, and that is useful information: a red test proves the assertion is actually exercising the code path. Atlas iterates with the edit tool until pnpm vitest reports green, keeping progress in a todowrite list when the module is large enough that a dozen exports need separate cases. When the vitest output overruns the inline cap, the retained log file means no failure is lost to a truncated tail. ## Where does Atlas put a new spec file in a TypeScript project? Atlas puts the new spec wherever your TypeScript repo already puts them, which grep tells it in 1 call. If src/lib/pricing.ts is covered by src/lib/pricing.test.ts, Atlas writes src/lib/cart.test.ts next to src/lib/cart.ts. If specs live under tests/unit/, Atlas writes there instead. Placement is not a style question in a TypeScript project, it is a resolution question. vitest picks up specs by an include glob, tsconfig decides whether test files are inside the compiled project or excluded, and path aliases resolve differently depending on the file's location in the tree. Writing a spec in the wrong directory produces a file that either fails to typecheck or never runs. Atlas derives the answer from evidence rather than convention: grep for existing .test.ts and .spec.ts files, read the closest one, and place the new file the same way. Atlas indexes code by AST declarations using tree-sitter, so the search for the sibling spec finds real declarations rather than arbitrary matches. Run prettier on the new file so it matches the formatting the rest of the repo enforces. ## How do I review TypeScript tests an AI agent wrote before they land? In 2026, Atlas surfaces the spec in the write tool's permission prompt as a diff before anything lands on disk, and every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs. Approving a new src/lib/cart.test.ts is therefore an explicit act, not a discovery you make later in git status. Reviewing an AI-written TypeScript spec takes about ninety seconds and is worth every one of them. Read for three things. Does the test assert on behavior, or does it assert on the implementation, mocking so much that a rewrite of the function would break the test without breaking the product? Does it cover every export documentSymbol listed, including the error branches, or only the happy path? Does it type-check under your tsconfig without an any or a cast smuggled in to make an assertion pass? Atlas gives you the diff up front, and Atlas snapshots file changes as git patches, so a spec you decide against can be diffed and rolled back cleanly. Once the spec is right, pnpm vitest is the arbiter and prettier keeps the file consistent with the rest of the repo. ## Steps 1. Start atlas in the project root, the directory with tsconfig.json, so the index picks up your type definitions, path aliases, and strictness settings. 2. Have Atlas read the untested module, for example src/lib/cart.ts, so the tests assert on real behavior rather than on the type signature. 3. Use the lsp tool's documentSymbol operation to enumerate the module's exported symbols so no public function is missed. 4. Grep for an existing .test.ts or .spec.ts file to copy the repo's framework, import style, path-alias usage, and naming convention. 5. Let Atlas write the new spec with the write tool, and read the diff in the permission prompt before it lands on disk. 6. Run the suite with the bash tool: pnpm vitest. Output over 2000 lines or 50 KB is truncated and the full log is saved to a file Atlas can read. 7. Iterate with the edit tool until vitest is green, keeping one todowrite entry per untested export when the module is large. 8. Run prettier on the new spec so it matches the repo's formatting, then approve the final diff. ## FAQ ### Can an AI agent write vitest tests for a TypeScript file that has none? Yes. Atlas reads the module, enumerates its exports with the lsp tool's documentSymbol operation, greps an existing .test.ts for conventions, writes the spec with the write tool, and runs pnpm vitest through bash until the suite is green. ### How do I make sure an AI agent covers every exported function in a TypeScript module? Use the symbol table, not a skim. Atlas calls the lsp tool's documentSymbol operation to enumerate exported symbols, so every exported function, class method, and factory in src/lib/cart.ts appears in the spec rather than only the ones the model happened to notice. ### Will Atlas use my existing test conventions or invent new ones? Atlas copies your existing conventions. It greps for an existing test file first, then matches the framework, the import style including tsconfig path aliases, the file naming pattern, and the mocking approach the repo already uses. ### Does Atlas actually run the TypeScript tests it generates? Yes. Atlas runs the spec with the bash tool and reads the failures. Output over 2000 lines or 50 KB is truncated and the complete log is saved to a file, so a noisy vitest run is triaged in full and Atlas iterates with edit until it passes. ### Where should vitest spec files live in a TypeScript project? Wherever the repo already puts them, because vitest resolves specs by an include glob and tsconfig decides what is in the project. Atlas greps for existing .test.ts and .spec.ts files and places the new spec the same way, then runs prettier on it. ### How do I review a test file an AI agent wrote before it hits my repo? The write tool shows the spec as a diff in the permission prompt before anything lands on disk, and every Atlas tool call is permission-gated against allow, ask, and deny rules. Atlas also snapshots file changes as git patches, so a rejected spec can be rolled back. ### Can Atlas write tests for a large TypeScript module without losing track? Yes. Atlas keeps progress in a todowrite list when the module is large, typically one entry per untested export, so a module with fifteen exports does not end up with tests for the first four and a confident summary about the rest. --- Canonical HTML: https://runatlas.sh/resources/stacks/write-unit-tests-for-untested-code-in-typescript Source of truth: aeo_pages row `/resources/stacks/write-unit-tests-for-untested-code-in-typescript` (segment: Stacks) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.