To run the full test suite and triage the failures in an Elixir project, have Atlas execute `mix test` through its bash tool with a generous timeout in milliseconds so a slow suite is not killed mid-run. ExUnit via mix test on a large umbrella app produces far more output than any model should read, so Atlas truncates the bash output at 2000 lines or 50 KB, writes the complete log to a retained file, and tells you the path. Triage then happens against the whole log with grep, grouping failures by root cause rather than by test name, and each distinct cause becomes one todowrite entry.
How does Atlas run a full mix test suite without drowning in output?
Atlas runs `mix test` through its bash tool and truncates the result at 2000 lines or 50 KB, writing the complete log to a retained file and reporting the path. A red ExUnit suite in a large Elixir umbrella app can emit tens of thousands of lines, so the retained file is the real artifact.
The bash tool is what executes `mix test` in an Elixir project, and it accepts a timeout in milliseconds. Pass a generous one: an ExUnit suite that boots a supervision tree, starts Ecto sandboxes, and exercises several OTP applications can take minutes, and a suite killed mid-run tells you nothing about which tests failed. When output exceeds the limits, Atlas emits an ...output truncated... header naming the file that holds the full log. That path is not a nicety, it is the input to the next step, because the tail of an ExUnit run shows the summary line but hides the individual failure blocks that actually explain what broke.
Why should I group ExUnit failures by root cause instead of by test name?
Forty red tests in an Elixir suite are rarely 40 bugs. A single changed struct field or a GenServer that no longer starts can fail dozens of ExUnit cases at once, so Atlas greps the saved `mix test` log for the repeated failure text and collapses it into a handful of distinct causes.
Test-name grouping is misleading in Elixir because ExUnit reports the failing assertion, not the origin. A MatchError from a changed pattern in `lib/my_app/accounts.ex` will surface in every test that touches accounts. Atlas uses grep over the retained log to count occurrences of each error type, ** (MatchError), ** (ArgumentError), ** (exit) from a crashed process, and then reads the relevant module with the read tool to confirm the shared source. Because Atlas indexes code by AST declarations using tree-sitter rather than blind line windows, locating the offending function head is precise rather than approximate.
How do I track distinct Elixir test failures so none get forgotten?
Atlas records one todowrite entry per distinct root cause, with status pending, so the fixes are tracked instead of forgotten. Triage of a red ExUnit suite typically collapses 40 failing tests into 3 or 4 causes, and each cause becomes one item on the list before any code is edited.
The todowrite list is the bridge between triage and repair. In an Elixir project the items read concretely: "Accounts.changeset/2 no longer accepts :email as a string, 14 ExUnit failures" or "MyApp.Worker fails to start under the supervisor, 6 failures". Keeping the list explicit prevents the classic mistake of fixing the loudest failure, re-running `mix test`, and discovering the remaining causes only by accident. Atlas fans out work to subagents that can run in the foreground or in parallel background sessions, so a large triage can be sliced across independent contexts while the main session keeps the todowrite list.
How do I fix Elixir test failures one at a time and re-run safely?
Atlas fixes causes 1 at a time with the edit tool and re-runs only the affected tests via bash between changes, for example `mix test test/my_app/accounts_test.exs`. Re-running the whole ExUnit suite after every one-line change wastes minutes and hides which fix actually worked.
Every Atlas edit is gated. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so a change to `lib/my_app/accounts.ex` is reviewed as a patch, not applied blind. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, which means `mix test` can be an allow rule while riskier shell commands stay on ask. Between fixes, run `mix format` so the diff does not mix logic changes with formatting noise. When all causes are cleared, run the full ExUnit suite once through bash to confirm the fixes did not collide.
What if my Elixir suite is too slow and Atlas kills it?
Pass a generous timeout in milliseconds to Atlas's bash tool when running `mix test`, because a slow Elixir suite killed mid-run produces no usable triage data. The bash tool truncates output at 2000 lines or 50 KB and writes the complete log to a retained file, so triage still runs against the whole log.
Timeouts and truncation are two different limits and both apply to `mix test`. The timeout governs how long the process may run; the 2000-line or 50 KB truncation governs how much of its output reaches the model. Set the timeout high enough that ExUnit reaches its summary line, then rely on the retained log file for the content. If the suite genuinely needs to be narrowed, `mix test --failed` or a single test file path keeps the run short while triage proceeds, and the full run is saved for the final green check.
Step by step
- 01Run the suite with Atlas's bash tool by invoking `mix test` in a project with a `mix.exs`, passing a generous timeout in milliseconds so a slow ExUnit run is not killed mid-run.
- 02If the output was truncated, read the file named in the ...output truncated... header with the read tool to see the complete `mix test` log rather than a lossy tail.
- 03Group the failures by root cause with grep over the saved log, counting repeated ExUnit errors like ** (MatchError) instead of listing test names.
- 04Read the shared module (for example `lib/my_app/accounts.ex`) to confirm the single change that produced the cluster of failures.
- 05Record one todowrite entry per distinct cause, with status pending, so the fixes are tracked instead of forgotten.
- 06Fix each cause with the edit tool and review the unified diff Atlas surfaces before it writes to disk.
- 07Re-run only the affected tests via bash, for example `mix test test/my_app/accounts_test.exs`, between changes rather than the whole suite.
- 08Run `mix format` to keep the diff clean, then run the full ExUnit suite via `mix test` once to confirm every cause is cleared.
Frequently asked questions
- how to triage a lot of failing exunit tests in elixir
- Run `mix test` through Atlas's bash tool, then read the retained log file Atlas names in its ...output truncated... header. Grep the log to group failures by root cause, since one changed function head can fail dozens of ExUnit cases, and record one todowrite entry per distinct cause.
- atlas bash output truncated where is the full mix test log
- Atlas truncates bash output at 2000 lines or 50 KB and writes the complete log to a retained file, then tells you the path in the ...output truncated... header. Read that file to see the full `mix test` output instead of the tail.
- mix test timeout in atlas
- Atlas's bash tool takes a timeout in milliseconds. Pass a generous value when running `mix test` on an umbrella project, because a suite killed mid-run gives you no failure blocks to triage.
- why do 40 exunit tests fail from one change
- ExUnit reports the failing assertion, not the origin. One changed struct field or a GenServer that will not start under the supervisor can fail every test that touches it. Group the failures by the repeated error text in the saved log rather than by test name.
- does atlas review its edits to my elixir modules
- Yes. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so a change to `lib/my_app/accounts.ex` is reviewed as a patch. Every tool call is also permission-gated against allow, ask, and deny rules.
- should i run the whole mix test suite after every fix
- No. Re-run only the affected tests via bash between changes, for example a single file path passed to `mix test`, then run the full ExUnit suite once at the end to confirm the fixes did not collide.
- how do i keep the elixir diff clean while fixing tests
- Run `mix format` after the edits so the patch contains logic changes rather than formatting noise. Atlas's edit tool surfaces the unified diff for approval, which makes formatting drift easy to spot before it lands.
- does atlas need mix.exs to work in an elixir project
- Run atlas in a project with a `mix.exs` and it reads your supervision tree, contexts, and deps managed by Mix and Hex. From there it can add ExUnit tests or restructure a GenServer, with each diff reviewed before it is written.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated 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 Elixir in 2026
Adopt Atlas, the terminal-native AI coding agent, for Elixir development in 2026. Enhance productivity with deep code understanding, safety features, and direct integration into mix projects and OTP applications.
Trace a Runtime Bug From a Stack Trace in Elixir with Atlas (2026)
Trace an Elixir runtime bug from a stack trace in 2026 with Atlas: read each frame at its offset, grep for the error message, findReferences the callers, fix, add ExUnit.
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.
Automate GitHub Issue and Pull Request Triage in Elixir with Atlas in 2026
Automate GitHub issue and pull request triage in Elixir projects using Atlas. Configure workflows to safely respond to events, ensuring only trusted users trigger actions and reviewing all changes.
Rename a symbol across the repo in Elixir with Atlas in 2026
Effortlessly rename Elixir functions, modules, or constants across your entire codebase in 2026 using Atlas. Leverage `lsp`, `grep`, and `edit` for precise, verified refactoring, ensuring your `mix test` suite remains
Audit an Elixir Repo with Parallel Subagents in 2026 using Atlas
Sweep your Elixir repository for specific problems without blowing your context window. Atlas uses parallel subagents, ExUnit, Mix, and Hex to audit large Elixir codebases efficiently.
Document an Elixir Module with a README in 2026 using Atlas
Generate accurate, up-to-date README documentation for your Elixir modules with Atlas. Leverage Mix, Hex, and ExUnit for verified, traceable docs.