how to add unit tests to an untested dart package

Have Atlas read the library, enumerate its exports with the lsp documentSymbol operation, grep an existing `_test.dart` for your conventions, write the new spec into `test/` with the write tool, then run `dart test`. Iterate with edit until the suite is green.

dart test not finding my test file

The Dart test runner discovers files under `test/` whose names end in `_test.dart`. A spec written anywhere else, or named without that suffix, simply never runs. Place `test/parser_test.dart` and re-run `dart test`.

atlas write tool permission for new test file

Atlas's write tool shows the diff in the permission prompt before anything lands on disk, so you can read the proposed `_test.dart` in full before approving. Every tool call is permission-gated against allow, ask, and deny rules.

how does atlas know my dart testing conventions

Atlas greps for an existing `_test.dart` file and copies the framework, import style, and naming it finds there. It also reads `analysis_options.yaml` so the new spec obeys your lint rules rather than tripping them on the first analyze.

dart test output too long to read

Atlas truncates bash output over 2000 lines or 50 KB and saves the full log to a file it names for you, so a noisy `dart test` run is still fully inspectable by reading that file.

should test packages go in dependencies or dev_dependencies

Test-only packages belong under dev_dependencies in `pubspec.yaml` and are installed with `pub`. Putting them under dependencies ships them to every consumer of your Dart library.

my new dart test fails immediately is the library broken

Usually not. A failing new spec most often means the test is wrong: an unresolved import, an omitted required named parameter, or an expect matcher used with the wrong type. Read the `dart test` failure before assuming the library is at fault.

does atlas cover private dart methods in tests

Atlas enumerates the exported surface with documentSymbol, and Dart's underscore prefix makes a member library-private. Testing goes through the public API that the documentSymbol list reports, which is the same surface a consumer of the package can call.

Write Unit Tests for Untested Code in Dart with Atlas (2026)

To write unit tests for untested code in a Dart package, have Atlas read the target library, copy the conventions your repo already uses rather than inventing its own, write the spec with the write tool, and then actually run it with `dart test`. The run is the point: a test that was never executed is not a test. Atlas starts by enumerating the module's exported symbols with the lsp tool's documentSymbol operation so no public function in `lib/src/` is missed, greps for an existing `_test.dart` file to copy the import style and naming, then writes the new spec into `test/` and executes it. Iterate with edit until `dart test` is green, keeping progress in a todowrite list when the library is large.

How does Atlas decide what to test in an untested Dart library?

Atlas reads the module under test, then uses the lsp tool's documentSymbol operation to enumerate its exported symbols so no public function is missed. In a Dart package a class in `lib/src/parser.dart` may expose 12 public members, and documentSymbol lists all of them rather than the 3 you happened to remember.

Enumeration first is what separates a real test suite from a plausible one. Dart's privacy rule is lexical: an underscore prefix makes a member library-private, so everything without one is public API that a consumer can call. documentSymbol surfaces exactly that set, including named constructors, factory constructors, getters, and top-level functions that are easy to overlook. Atlas indexes code by AST declarations using tree-sitter, not blind line windows, so the declaration list it works from matches what the analyzer sees rather than a regex approximation.

How does Atlas match my existing Dart test conventions?

Atlas greps for an existing `_test.dart` file and copies 3 things from it: the framework, the import style, and the naming convention. A Dart repo that already imports `package:test/test.dart` and structures cases as group and test blocks should get more of the same, not a second style bolted alongside the first.

Convention matching is a concrete grep, not a vibe. Atlas looks for how your existing tests import the library under test, whether by a relative path or by `package:my_app/...`, whether they use group blocks and what those groups are named, whether setUp is used or fixtures are constructed inline, and whether expect matchers or a mocking package appear. It also reads `analysis_options.yaml`, because a repo with strict lints will reject a new `_test.dart` that ignores them. Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion, so a convention used in only one distant test file is still found.

How does Atlas create a new Dart test file safely?

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 gated against 3 rule types, allow, ask, and deny, so a new `test/parser_test.dart` is fully readable before it is created.

Writing a test file is one of the safer things an agent can do, and Atlas still gates it. The permission prompt shows the complete proposed `_test.dart`, so you can see whether the assertions are real or whether the agent wrote three cases that all assert something trivially true. Read the expect calls before approving. Atlas snapshots file changes as git patches, so a spec file that turns out to be wrong can be diffed and rolled back rather than hand-deleted. Placing the file correctly matters too: Dart's test runner discovers files under `test/` whose names end in `_test.dart`, and a file placed elsewhere simply never runs.

Why must Atlas run dart test rather than just write the tests?

A Dart test that was never executed is not a test. Atlas runs the suite with the bash tool by invoking `dart test`, and reads the failures. Output over 2000 lines or 50 KB is truncated and the full log is saved to a file you can read, so a noisy package suite is still fully inspectable.

Unrun tests fail in predictable ways: an import that does not resolve, a constructor whose required named parameter was omitted, a null-safety violation that only the analyzer catches, an expect matcher used with the wrong type. Running `dart test` surfaces all of it in seconds. When the first run is red, read the failures rather than rewriting the spec from scratch, because a failing new test frequently means the test is wrong, not the library. Atlas iterates with the edit tool until the suite is green, keeping progress in a todowrite list when the library under test is large enough that one pass will not finish it.

How do I keep new Dart test files consistent with the package?

Dart test files obey the same rules as package source in 2026: run `dart format` over the new `test/parser_test.dart` before committing, and declare any test-only package under dev_dependencies in `pubspec.yaml`, installed with `pub`, never as a runtime dependency.

A Dart test suite is part of the package, so it obeys the package's rules. `dart format` normalizes the trailing-comma-driven layout that Dart's formatter enforces, which keeps the diff readable. The `pubspec.yaml` distinction between dependencies and dev_dependencies matters because a test-only package added to the wrong section ships to every consumer of your library. Once `dart test` is green and `dart format` has run, review the whole diff. Atlas reads git branches, status, and diffs, and can stage and create commits on your behalf once the suite passes.

Step by step

01Read the Dart library under test with the read tool, then use the lsp tool's documentSymbol operation to enumerate its exported symbols so no public function in `lib/src/` is missed.
02Grep for an existing `_test.dart` file to copy the repo's framework, import style, group and test naming, and whether setUp is used.
03Read `analysis_options.yaml` so the new spec obeys the package's lint rules instead of tripping them on the first analyze.
04Write the new spec file with the write tool into `test/`, ending the filename in `_test.dart` so the Dart test runner discovers it; the permission prompt shows the diff before anything lands on disk.
05Run the suite with the bash tool by invoking `dart test`, 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 `dart test` is green, remembering that a failing new spec usually means the test is wrong, not the library.
07Keep progress in a todowrite list when the library exposes enough public members that one pass will not cover them all.
08Run `dart format` on the new test file, confirm any test-only package sits under dev_dependencies in `pubspec.yaml`, and install it with `pub`.

Frequently asked questions

how to add unit tests to an untested dart package: Have Atlas read the library, enumerate its exports with the lsp documentSymbol operation, grep an existing `_test.dart` for your conventions, write the new spec into `test/` with the write tool, then run `dart test`. Iterate with edit until the suite is green.
dart test not finding my test file: The Dart test runner discovers files under `test/` whose names end in `_test.dart`. A spec written anywhere else, or named without that suffix, simply never runs. Place `test/parser_test.dart` and re-run `dart test`.
atlas write tool permission for new test file: Atlas's write tool shows the diff in the permission prompt before anything lands on disk, so you can read the proposed `_test.dart` in full before approving. Every tool call is permission-gated against allow, ask, and deny rules.
how does atlas know my dart testing conventions: Atlas greps for an existing `_test.dart` file and copies the framework, import style, and naming it finds there. It also reads `analysis_options.yaml` so the new spec obeys your lint rules rather than tripping them on the first analyze.
dart test output too long to read: Atlas truncates bash output over 2000 lines or 50 KB and saves the full log to a file it names for you, so a noisy `dart test` run is still fully inspectable by reading that file.
should test packages go in dependencies or dev_dependencies: Test-only packages belong under dev_dependencies in `pubspec.yaml` and are installed with `pub`. Putting them under dependencies ships them to every consumer of your Dart library.
my new dart test fails immediately is the library broken: Usually not. A failing new spec most often means the test is wrong: an unresolved import, an omitted required named parameter, or an expect matcher used with the wrong type. Read the `dart test` failure before assuming the library is at fault.
does atlas cover private dart methods in tests: Atlas enumerates the exported surface with documentSymbol, and Dart's underscore prefix makes a member library-private. Testing goes through the public API that the documentSymbol list reports, which is the same surface a consumer of the package can call.

Try Atlas in your terminal

The terminal-native AI coding agent. Free core, single binary.

Install Atlas

Related 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 Dart in 2026

Adopt Atlas, the terminal-native AI coding agent, for Dart development in 2026. Enhance productivity with intelligent code search, refactoring, and robust safety features across your Dart projects.

Automate GitHub issue and pull request triage in Dart with Atlas in 2026

Automate GitHub issue and pull request triage for your Dart projects with Atlas. Safely respond to events, manage dependencies with `pub`, and ensure code quality with `dart format`.

Onboard to an Unfamiliar Dart Codebase with Atlas (2026)

Onboard to an unfamiliar Dart codebase with Atlas in 2026. Start from meaning with codebase_search, map lib/ with glob, and delegate wide sweeps to a read-only explore subagent.

Research a Third-Party API Before Integrating It in Dart with Atlas (2026)

Atlas researches a third-party API for a Dart integration with websearch and webfetch behind permission prompts, then writes null-safe code verified by dart test.

Refactor a Legacy Dart Module with Atlas in 2026

Safely refactor legacy Dart modules in 2026 with Atlas. Leverage `dart test`, `pub`, and `lsp` to restructure code without breaking callers or changing behavior.

Migrate a deprecated API across every callsite in Dart with Atlas in 2026

In 2026, use Atlas to systematically migrate deprecated Dart APIs across your entire codebase. Leverage `pub`, `dart test`, and `dart format` for a complete, verified transition.

Locate Where a Behavior Is Implemented in Dart with Atlas (2026)

Find the exact Dart file and symbol behind a behavior with Atlas in 2026, using codebase_search for meaning, grep for text, and the lsp tool for the symbol graph.

Browse this resource hub