Stacks

Run the Test Suite and Triage the Failures in Dart with Atlas (2026)

Updated 8 min read

To run a Dart test suite and triage the failures with Atlas, run `dart test` through the bash tool with a generous timeout in milliseconds so a slow suite is not killed mid-run. 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 triage happens against the whole log rather than a lossy tail. Group the failures by root cause with grep over that saved log rather than by test name, since 40 red tests in test/ usually trace back to 3 or 4 causes. Record one todowrite entry per distinct cause, fix them one at a time with edit, and re-run only the affected test files between changes.

How do you run a Dart test suite through Atlas?

Atlas runs a Dart test suite with dart test through the bash tool, passing a generous timeout in milliseconds so a slow suite is not killed mid-run. Output is truncated at 2000 lines or 50 KB, with the complete log retained to a file whose path Atlas reports, so triage happens against the whole run.

Run atlas in a package with a pubspec.yaml and let Atlas read your libraries, pub dependencies, and analysis options. The bash tool takes an explicit timeout in milliseconds, and setting it generously is step one of Atlas's documented triage workflow for a reason: a killed run gives you a partial failure set, and a partial failure set sends you chasing causes that do not exist. Let pub resolve the dependencies first so the run is against the versions pubspec.lock pins. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so allowing `dart test` is an explicit choice you make once.

What happens when dart test output is too long for Atlas 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 in an ...output truncated... header. A `dart test` run with 200 failing tests easily exceeds that, and the retained file is what makes full triage possible.

A full Dart suite produces far more output than any model should read, and a truncated tail is the worst possible input for triage because the first failures, which are usually the causal ones, are the ones that get cut. Atlas's approach is to truncate what it shows while retaining what it captured. When you see the ...output truncated... header, read the file named in it to see the complete log. From there the whole run is available for grep, including the stack traces from the earliest failures and the analysis options warnings that scrolled past. That retained log is the artifact the rest of the triage works against.

How do you group Dart test failures by root cause?

Atlas groups Dart test failures by root cause with grep over the saved log, not by test name. When 40 tests in test/ go red, the useful question is not which 40, it is which 3 distinct causes produced them, and grepping the retained log for the repeated exception type answers that far faster than reading test names.

Dart failures cluster. A single null check operator used on a null value after a migration, one MissingPluginException, and one changed constructor signature will light up dozens of unrelated test files. Grep the retained log for the exception class, the failing assertion message, or the shared stack frame, and the clusters fall out immediately. Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion, so once you have the cause you can ask codebase_search where that behavior lives in lib/ rather than guessing at file paths. Atlas indexes code by AST declarations using tree-sitter, not blind line windows, so the read tool returns whole Dart functions and classes when you follow the trail into lib/src.

How does Atlas track distinct Dart failure causes?

Atlas records one todowrite entry per distinct Dart failure cause, with status pending, so the fixes are tracked instead of forgotten. Three causes behind 40 red `dart test` results become three tracked items, and a fix that closes one of them cannot be mistaken for a fix that closed the suite.

Triage produces a list, and the list has to survive the fixing. Atlas's todowrite tool is where it lives, one entry per cause rather than one per failing test, which is the whole point of grouping first. Atlas fans out work to subagents that can run in the foreground or in parallel background sessions, so independent causes in a large Dart package can be investigated in parallel while the main session keeps the list. As each cause is fixed and the affected test files go green, the entry moves out of pending, and what remains is an honest picture of how much of the suite is actually repaired.

How do you fix Dart test failures one at a time with Atlas?

Atlas fixes Dart failures 1 at a time with the edit tool, re-running only the affected tests via bash between changes. Running the full dart test suite after every edit wastes minutes on a large package, and running it only once at the end destroys the attribution that made the triage worth doing.

Fix the first cause with edit, then run `dart test test/orders_test.dart` rather than the whole suite, and confirm that cluster is green before moving on. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so a change to lib/src/orders.dart is visible before it lands. Run `dart format` on the touched files so the fix diff carries no style churn, and let pub handle any dependency change the fix required. When every todowrite entry is closed, run the full `dart test` suite once more through bash to confirm the whole package is green. Atlas snapshots file changes as git patches so edits can be diffed and rolled back if a fix turns out to be the wrong one.

Step by step

  1. 01Run atlas in a package with a pubspec.yaml and let Atlas read your libraries, pub dependencies, and analysis options.
  2. 02Run the suite with `dart test` through the bash tool, passing a generous timeout in milliseconds so a slow suite is not killed mid-run.
  3. 03If the output was truncated, read the file named in the ...output truncated... header to see the complete log; bash truncates at 2000 lines or 50 KB but retains the whole run.
  4. 04Group the failures by root cause with grep over the saved log rather than by test name, searching for the repeated exception class or stack frame.
  5. 05Record one todowrite entry per distinct cause, with status pending, so the fixes are tracked instead of forgotten.
  6. 06Use codebase_search to locate the Dart code in lib/ responsible for each cause instead of guessing at file paths.
  7. 07Fix each cause with edit, approving the unified diff Atlas surfaces before it writes to lib/src.
  8. 08Re-run only the affected test file with `dart test test/<file>_test.dart` between changes, not the whole suite.
  9. 09Run `dart format` on the touched Dart files so the fix diff carries no style churn.
  10. 10Run the full `dart test` suite once more through bash when every todowrite entry is closed.

Frequently asked questions

How do I triage a failing dart test suite with an AI agent?
Run `dart test` through Atlas's bash tool with a generous timeout in milliseconds, read the retained log if the output was truncated, grep it to group the failures by root cause, and record one todowrite entry per distinct cause.
Why is my dart test output truncated in Atlas?
Atlas's bash tool truncates at 2000 lines or 50 KB. It writes the complete log to a retained file and tells you the path in the ...output truncated... header, so you read the whole run from that file rather than from a lossy tail.
How do I stop Atlas from killing a slow dart test run?
Pass a generous timeout in milliseconds to the bash tool. A killed run gives you a partial failure set, which sends triage chasing causes that do not exist in the full suite.
Should I group Dart test failures by test name or by error?
By error. Atlas groups failures by root cause with grep over the saved log rather than by test name, because 40 red tests in a Dart package usually trace back to only 3 or 4 distinct causes.
Does Atlas re-run the whole Dart suite after every fix?
No. Atlas fixes causes one at a time with edit and re-runs only the affected tests via bash between changes, then runs the full `dart test` suite once at the end when every todowrite entry is closed.
Can Atlas work with pub and pubspec.yaml?
Yes. Run atlas in a package with a pubspec.yaml and Atlas reads your libraries, pub dependencies, and analysis options. It drives pub and `dart test` through the bash tool once those commands are allowed by your permission rules.
Will Atlas run dart format on the files it fixed?
Atlas runs `dart format` through the bash tool on the touched files, so the fix diff shows the behavior change and not a page of reformatting.
Can I undo a Dart fix Atlas applied?
Yes. Atlas snapshots file changes as git patches so edits can be diffed and rolled back, and it computes a unified diff for every file edit and surfaces it for approval before writing in the first place.

Try Atlas in your terminal

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

Install Atlas

Related guides

Run the Test Suite and Triage the Failures with Atlas in 2026

How to triage a failing test suite with Atlas in 2026: bash truncates at 2000 lines or 50 KB and saves the full log, then grep groups failures by root cause.

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.

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

Add tests to an untested Dart library in 2026. Atlas enumerates exports with lsp documentSymbol, copies your test conventions, writes the spec, and runs dart test.

Debug a Single Failing Test in Dart with Atlas (2026)

Debug one failing Dart test with Atlas in 2026: isolate it with dart test, walk the call path with the lsp tool, and fix the code rather than the assertion.

Diagnose a Hanging or Long-Running Dart Command with Atlas in 2026

In 2026, use Atlas to diagnose why your Dart builds or scripts are hanging. Learn to distinguish genuinely slow `pub` or `dart test` commands from those blocked on interactive input, and get them unstuck.

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.

Document a Dart Module with a README in 2026 using Atlas

In 2026, Atlas helps Dart developers generate accurate README documentation directly from source code. It uses pub and dart test to ensure docs reflect current module behavior, not outdated plans.

Browse this resource hub