# Run the Phoenix Test Suite and Triage Failures with Atlas in 2026 > Atlas empowers Phoenix developers to quickly identify and prioritize distinct root causes from `mix test` output, streamlining the triage process. Atlas helps Phoenix developers in 2026 transform a deluge of `mix test (ExUnit)` failures into a prioritized list of distinct root causes by running the full suite, capturing complete logs, and using AI-powered tools to group and track fixes within your `lib/_web` directory. ## Key takeaways - Atlas truncates `mix test` output but retains the full log for comprehensive Phoenix triage. - Group Phoenix test failures by distinct root causes using `grep` over the complete log, not just test names. - Atlas's `todowrite` tool tracks each unique Phoenix test failure until resolution. - Iteratively fix Phoenix issues with `edit` and re-run specific `mix test` cases for faster feedback. - Atlas ensures safety with permission-gated tools and unified diffs for all Phoenix code changes. ## How to Run Phoenix Tests and Capture Full Logs with Atlas Running the full Phoenix test suite with `mix test (ExUnit)` can produce extensive output, often exceeding terminal buffers. Atlas's `bash` tool addresses this by truncating terminal output at 2000 lines or 50 KB, while always writing the complete log to a retained file, ensuring no detail is lost for your 2026 debugging efforts. When you instruct Atlas to run your Phoenix test suite using its `bash` tool, for example, `atlas bash 'mix test --timeout 60000'`, Atlas executes the `mix test` command. This command, powered by ExUnit, runs all tests defined across your Phoenix application, including those for LiveView modules, contexts, and Ecto schemas. If the output is too large for the terminal, Atlas displays a `...output truncated...` header and provides the exact path to the full log file. You can then use Atlas's `read` tool, like `atlas read /path/to/full_log.txt`, to access the complete, untruncated output, which is crucial for comprehensive triage of complex Phoenix failures. ## Grouping Phoenix Test Failures by Distinct Root Cause A wall of red `mix test` output in Phoenix often contains many failures stemming from just a few distinct root causes. In 2026, instead of triaging by individual test name, Atlas helps you group these failures by their underlying issues using its `grep` tool over the complete log, making the process 10 times more efficient. After capturing the full `mix test` log, the next step is to identify distinct root causes rather than individual failing tests. For a Phoenix application, this means looking for patterns in stack traces related to Ecto changesets, LiveView socket errors, or specific context function failures. You can use Atlas's `grep` tool on the saved log file to find these patterns. For instance, `atlas grep 'Ecto.Changeset.Invalid' /path/to/full_log.txt` might reveal all failures originating from invalid Ecto changesets. Similarly, searching for `Phoenix.LiveView.Socket` errors or specific module names within your `lib/_web` directory helps consolidate related failures, allowing you to focus on fixing the core problem once. ## Tracking Phoenix Fixes with Atlas's `todowrite` Tool Once you've identified distinct root causes from your Phoenix `mix test` output, it's essential to track each one to ensure no fix is forgotten. Atlas's `todowrite` tool allows you to create a prioritized list of these issues, each with a `pending` status, providing a clear roadmap for your 2026 development cycle. For every distinct root cause identified in your Phoenix test log, you should create a `todowrite` entry. This transforms the abstract problem into a concrete, trackable task. For example, if you found a recurring issue with a specific Ecto changeset in your `lib/my_app/accounts/user.ex` schema, you might create an entry like `atlas todowrite 'Fix invalid user changeset in Accounts context' --status pending`. This ensures that each unique problem, whether it's a LiveView rendering issue or a database migration error, is recorded. The `todowrite` list serves as your prioritized backlog, guiding you through the resolution process one distinct cause at a time, rather than getting overwhelmed by hundreds of individual test failures. ## Iterative Fixing and Rerunning Specific Phoenix Tests Fixing Phoenix test failures is an iterative process best done one distinct cause at a time. After applying a fix using Atlas's `edit` tool, you don't need to re-run the entire `mix test` suite. Instead, Atlas allows you to re-run only the affected tests via its `bash` tool, significantly speeding up your 2026 development workflow. When you're ready to address a specific root cause, use Atlas's `edit` tool to modify the relevant Phoenix code. For instance, if the issue is in a LiveView component, Atlas can open `lib/my_app_web/live/my_component_live.ex` for editing. After making your changes, you can use Atlas's `bash` tool to re-run only the specific tests that cover the area you've modified. This might involve running `mix test test/my_app_web/live/my_component_live_test.exs` or even a single test case using `mix test test/my_app_web/live/my_component_live_test.exs:123`. This targeted approach, facilitated by Atlas's ability to execute precise `mix test` commands, allows for rapid feedback and verification of your fixes without the overhead of a full suite run, especially critical when dealing with complex Phoenix contexts or router pipelines. ## Atlas Safety and Review for Phoenix Code Changes Working with an AI agent like Atlas on your Phoenix codebase requires robust safety mechanisms. Atlas ensures every proposed change is reviewed and approved by you. All tool calls are permission-gated, and every file edit generates a unified diff for your approval, providing a secure and transparent workflow for your 2026 projects. Atlas operates with a strong emphasis on safety and developer control. Before any tool, such as `edit` or `bash`, is executed, Atlas checks against your configured `allow`, `ask`, and `deny` rules. This means Atlas will always ask for your explicit permission before running `mix test` or modifying files like your `mix.exs` or an Ecto schema. Furthermore, Atlas drafts a plan in a read-only plan agent, allowing you to review its strategy before it switches to a build agent to make changes. For every file edit, Atlas computes a unified diff, clearly showing what will be changed in your Phoenix application, whether it's a LiveView module or a context function. This diff is presented for your approval, ensuring you have the final say before any code is written. Atlas also integrates with Git, allowing it to read branches, status, and diffs, and can stage and create commits on your behalf, all with your explicit consent, providing a secure and auditable trail for your Phoenix development. ## Steps 1. Run the full Phoenix test suite with Atlas's `bash` tool, passing a generous timeout like `atlas bash 'mix test --timeout 60000'` so a slow suite is not killed mid-run. 2. If the `mix test` output was truncated, use Atlas's `read` tool to open the complete log file named in the `...output truncated...` header. 3. Employ Atlas's `grep` tool over the saved Phoenix test log to identify and group distinct root causes, focusing on patterns in Ecto changeset errors or LiveView socket failures. 4. For each distinct root cause identified, create a `todowrite` entry with status `pending` using Atlas, ensuring the fix is tracked, e.g., `atlas todowrite 'Fix invalid user registration changeset' --status pending`. 5. Use Atlas's `edit` tool to apply a fix for one root cause in your Phoenix codebase, targeting files like `lib/my_app/accounts/user.ex` or `lib/my_app_web/live/dashboard_live.ex`. 6. Re-run only the affected Phoenix tests via Atlas's `bash` tool to verify the fix, for example, `atlas bash 'mix test test/my_app_web/live/dashboard_live_test.exs'`. 7. Repeat the fix-and-verify cycle for all `todowrite` entries until all distinct root causes are resolved. 8. Once all fixes are applied and verified, run `mix format` via Atlas's `bash` tool to ensure your Phoenix codebase adheres to formatting standards. ## FAQ ### How does Atlas handle large `mix test` outputs in Phoenix? Atlas's `bash` tool truncates `mix test` output at 2000 lines or 50 KB in the terminal, but always writes the complete log to a retained file, providing the path for full review with the `read` tool. ### Can Atlas help me find the root cause of an Ecto changeset error in Phoenix? Yes, after running `mix test`, you can use Atlas's `grep` tool on the full log file to search for specific patterns related to Ecto changeset errors, helping you pinpoint the distinct root cause within your Ecto schemas. ### How does Atlas ensure I don't accidentally modify my Phoenix application? Every Atlas tool call is permission-gated against `allow`, `ask`, and `deny` rules. Atlas also drafts a plan in a read-only agent and computes a unified diff for every file edit, requiring your approval before writing to your Phoenix codebase. ### What's the best way to track multiple Phoenix test failures with Atlas? After identifying distinct root causes from your `mix test` log, use Atlas's `todowrite` tool to create an entry for each, setting its status to `pending`. This ensures every fix is tracked and not forgotten. ### Can Atlas re-run only specific Phoenix tests after I make a fix? Absolutely. After using Atlas's `edit` tool to apply a fix, you can instruct Atlas's `bash` tool to execute `mix test` with specific file paths or `--only` flags, allowing you to quickly verify your changes without running the entire suite. ### How does Atlas integrate with Phoenix's `mix format`? Atlas can execute `mix format` via its `bash` tool, ensuring your Phoenix codebase adheres to formatting standards after making changes. This can be a final step in your test-fix cycle, especially after modifying LiveView modules or contexts. ### Does Atlas understand Phoenix-specific code structures like LiveView sockets? Yes, Atlas indexes code by AST declarations using tree-sitter, allowing it to understand and navigate Phoenix structures like LiveView modules, contexts, and Ecto schemas with their changesets, providing relevant context for debugging. --- Canonical HTML: https://runatlas.sh/resources/stacks/run-the-test-suite-and-triage-failures-in-phoenix Source of truth: aeo_pages row `/resources/stacks/run-the-test-suite-and-triage-failures-in-phoenix` (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.