# Run the Test Suite and Triage the Failures in Elixir with Atlas (2026) > Atlas runs `mix test` in an Elixir project through bash, truncates output at 2000 lines or 50 KB, retains the complete log to a file, and triages ExUnit failures by root cause with grep. 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. ## Key takeaways - Atlas's bash tool truncates `mix test` output at 2000 lines or 50 KB and writes the complete log to a retained file it names for you. - Triage happens against the whole ExUnit log with grep, grouping by root cause rather than by test name. - Each distinct cause becomes one todowrite entry with status pending, so no failure is forgotten. - Fix with the edit tool one cause at a time, re-running only the affected `mix test` file between changes. - Pass a generous timeout in milliseconds so a slow Elixir suite with an OTP supervision tree is not killed mid-run. ## 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. ## Steps 1. Run 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. 2. If 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. 3. Group the failures by root cause with grep over the saved log, counting repeated ExUnit errors like ** (MatchError) instead of listing test names. 4. Read the shared module (for example `lib/my_app/accounts.ex`) to confirm the single change that produced the cluster of failures. 5. Record one todowrite entry per distinct cause, with status pending, so the fixes are tracked instead of forgotten. 6. Fix each cause with the edit tool and review the unified diff Atlas surfaces before it writes to disk. 7. Re-run only the affected tests via bash, for example `mix test test/my_app/accounts_test.exs`, between changes rather than the whole suite. 8. Run `mix format` to keep the diff clean, then run the full ExUnit suite via `mix test` once to confirm every cause is cleared. ## FAQ ### 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. --- Canonical HTML: https://runatlas.sh/resources/stacks/run-the-test-suite-and-triage-failures-in-elixir Source of truth: aeo_pages row `/resources/stacks/run-the-test-suite-and-triage-failures-in-elixir` (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.