# Debug a single failing test in Phoenix with Atlas in 2026 > Atlas empowers Phoenix developers to efficiently debug single failing tests by integrating directly with `mix test (ExUnit)` and providing AI-driven code analysis. In 2026, Atlas helps Phoenix developers debug a single failing test by running `mix test (ExUnit)` in isolation, analyzing the code, and proposing fixes directly within your terminal. It integrates with your existing Phoenix toolchain, allowing you to quickly identify and resolve issues in your LiveView modules, Ecto schemas, and contexts. ## Key takeaways - Atlas integrates directly with `mix test (ExUnit)` for focused Phoenix test debugging. - The `lsp` tool helps navigate Phoenix contexts, LiveView modules, and Ecto schemas with precision. - Atlas uses `bash` to execute Phoenix commands like `mix test` with specific ExUnit filter flags. - Code changes are proposed as unified diffs for explicit approval before writing to Phoenix files. - Atlas ensures safety with permission-gated tools and a read-only planning agent for Phoenix development. ## How Atlas identifies failing Phoenix tests with `mix test` Atlas streamlines debugging in Phoenix by running a single failing test with `mix test` via its `bash` tool, ensuring a focused output for analysis. This approach, common in 2026, allows Atlas to precisely target the problem area, often reducing diagnostic time by over 50% compared to running a full suite. When a Phoenix test fails, Atlas uses its `bash` tool to execute `mix test` with specific ExUnit filter flags. For instance, Atlas can run `mix test --only 'MyPhoenixAppWeb.SomeTest'` or `mix test --trace 'MyPhoenixAppWeb.AnotherTest'` to isolate the problematic test. This focused execution ensures that the output is minimal and directly relevant to the failure, making it easier for Atlas to parse and understand the assertion message. By leveraging `bash`, Atlas interacts with your Phoenix project exactly as you would from the terminal, providing a familiar and powerful debugging environment. After running the test, Atlas employs its `read` tool to ingest the test output, pinpointing the exact failure and preparing for deeper code analysis within your Phoenix application. ## Walking the Phoenix call graph with Atlas LSP for Ecto and LiveView After identifying a failing Phoenix test, Atlas uses its `lsp` tool to work through the code, tracing the call graph from the test assertion into your application's LiveView modules, Ecto schemas, or contexts. This deep dive, powered by tree-sitter AST indexing, provides a 360-degree view of the execution flow, crucial for understanding complex interactions. Once Atlas has identified the failing Phoenix test, it uses its `lsp` tool to perform `goToDefinition` and `findReferences` operations. This allows Atlas to trace the execution path from the test assertion back through the application code it exercises. For a Phoenix developer, this means Atlas can navigate from a test in `test/my_phoenix_app_web/live/some_live_test.exs` directly into the corresponding LiveView module in `lib/my_phoenix_app_web/live/some_live.ex`. Similarly, if the test involves data persistence, Atlas can follow the call stack into an Ecto context in `lib/my_phoenix_app/accounts/accounts.ex` and then to an Ecto schema and its changeset in `lib/my_phoenix_app/accounts/user.ex`. Atlas's ability to index code by AST declarations using tree-sitter ensures precise navigation, even across complex Phoenix idioms like nested contexts or LiveView socket interactions, providing a clear understanding of the code's behavior. ## Forming and testing hypotheses in Phoenix with Atlas's `edit` and `bash` tools To validate a hypothesis about a failing Phoenix test, Atlas leverages its `edit` tool to insert temporary logging or modifies `mix test` commands via `bash` to enable verbose output. This iterative process, often involving 2-3 cycles of testing and refinement, helps pinpoint the exact line of code causing the failure in your Phoenix application. With a clear understanding of the call graph, Atlas forms a hypothesis about the root cause of the failing Phoenix test. To test this hypothesis, Atlas can use its `edit` tool to temporarily insert debugging statements, such as `IO.inspect/2` or `Logger.debug/1`, directly into the relevant Phoenix LiveView module, Ecto context, or utility function. After adding logging, Atlas re-runs the single failing test using `bash` and `mix test` to observe the output. Alternatively, Atlas can modify the `mix test` command to include verbose flags, like `mix test --verbose` or `mix test --trace`, to get more detailed runtime information. This iterative process of modifying code or test execution parameters and re-running the test allows Atlas to gather more data, refine its understanding, and ultimately confirm the exact location and nature of the bug in your Phoenix codebase. Any temporary logging added is tracked and removed by Atlas once the fix is confirmed. ## Applying code fixes and reviewing changes in Phoenix with Atlas Once the root cause of a failing Phoenix test is identified, Atlas applies fixes to your production code using its `edit` or `apply_patch` tools. Every proposed change generates a unified diff, allowing you to review and approve modifications before they are written to disk, ensuring 100% control over your codebase. After successfully identifying and confirming the bug, Atlas proceeds to fix the production code in your Phoenix application. For minor, localized changes, Atlas uses its `edit` tool to directly modify the relevant file, such as a function in an Ecto context or a LiveView component. If the fix spans multiple hunks or involves more complex structural changes, Atlas can generate and apply a `git` patch using its `apply_patch` tool, ensuring atomic and reliable modifications. Crucially, for every proposed edit, Atlas computes a unified diff and surfaces it for your approval. This means you always see exactly what changes Atlas intends to make to your Phoenix files, whether it's in `lib/my_phoenix_app/accounts/user.ex` or `lib/my_phoenix_app_web/controllers/page_controller.ex`. You maintain full control, approving or rejecting changes before they are written. After applying the fix, Atlas re-runs the single failing test to confirm the resolution, then runs the full `mix test` suite to ensure no regressions were introduced, and finally, can run `mix format` to ensure code style consistency. ## Ensuring safety and control with Atlas in Phoenix development Atlas prioritizes safety and developer control in Phoenix workflows, with every tool call permission-gated against allow, ask, and deny rules. Before any code modification, Atlas drafts a plan in a read-only agent and presents a unified diff for approval, giving you 100% oversight of changes to your `mix.exs` or LiveView modules. Atlas is designed with robust safety mechanisms to ensure developers maintain complete control over their Phoenix projects. Every Atlas tool call, including `bash`, `edit`, and `apply_patch`, is permission-gated. You can configure Atlas with `allow`, `ask`, or `deny` rules, ensuring that no action is taken without your explicit consent, especially when interacting with critical files like `mix.exs` or your Ecto schemas. Before Atlas proposes any code changes, it first drafts a comprehensive plan in a read-only plan agent. This plan outlines the steps Atlas intends to take, allowing you to review its strategy without any risk of unintended modifications. Furthermore, any file edit Atlas suggests is presented as a unified diff for your approval. This transparent process means you always have the final say on changes to your Phoenix application, from LiveView modules to context functions. Atlas also snapshots file changes as git patches, providing an easy way to diff edits and roll back if necessary, adding another layer of safety to your development workflow. ## Steps 1. Run just the failing Phoenix test with Atlas `bash`, using `mix test --only 'MyPhoenixAppWeb.SomeTest'` to isolate the issue. 2. Read the Phoenix test and the module it exercises using Atlas `read`, focusing on the assertion and the code path. 3. Walk the Phoenix call path with Atlas `lsp`'s `goToDefinition` and `findReferences` to explore LiveView modules, Ecto schemas, or contexts. 4. Form a hypothesis and check it by adding temporary logging with Atlas `edit` (e.g., `IO.inspect`) or re-running `mix test` with a verbose flag (e.g., `mix test --trace`) via Atlas `bash`. 5. Fix the production Phoenix code with Atlas `edit` for small changes or `apply_patch` for multi-hunk modifications, reviewing the unified diff for approval. 6. Re-run the single Phoenix test, then the full suite with `mix test`, and remove any temporary logging you added using Atlas `edit`. ## FAQ ### How does Atlas run `mix test` for a single failing test? Atlas uses its `bash` tool to execute `mix test` with specific ExUnit filter flags, such as `--only` or `--trace`, allowing it to isolate and run just the problematic Phoenix test. ### Can Atlas help me understand Ecto changesets in a failing test? Yes, Atlas can use its `lsp` tool to navigate from your Phoenix test into Ecto schemas and their changesets, helping you trace data transformations and validation logic within your application. ### What if my Phoenix test involves LiveView sockets? Atlas's `lsp` tool can follow references and definitions within your LiveView modules, including socket handling, to help you understand the flow of events and state changes that might be causing a test to fail. ### How does Atlas ensure I approve code changes to my Phoenix application? Before writing any changes, Atlas presents a unified diff for your review and approval. It also operates with permission-gated tools and a read-only planning agent, giving you full control over modifications to your Phoenix codebase. ### Can Atlas help me refactor Phoenix business logic from a controller to a context? Yes, Atlas is capable of moving business logic from a Phoenix controller into a context function, ensuring it returns an `ok` or `error` tuple as per Phoenix idioms, and can then run `mix format`. ### Does Atlas support `mix format` for Phoenix code? Yes, Atlas can run `mix format` via its `bash` tool to ensure your Phoenix codebase adheres to formatting standards, often as a final step after applying code fixes or refactorings. ### How does Atlas handle dependencies managed by Hex in Phoenix projects? While debugging, Atlas focuses on code analysis and modification. For dependency management, you would typically run `mix deps.get` via Atlas's `bash` tool if new dependencies were introduced or updated in your Phoenix project. ### Can Atlas generate Ecto migrations for Phoenix? Yes, Atlas can generate Ecto migrations and will show you the `up` and `down` functions for review before you allow it to interact with your database, ensuring safety and transparency. --- Canonical HTML: https://runatlas.sh/resources/stacks/debug-a-failing-test-in-phoenix Source of truth: aeo_pages row `/resources/stacks/debug-a-failing-test-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.