# Debug a Single Failing Test in Elixir with Atlas (2026) > Atlas isolates one red ExUnit case with `mix test test/my_app/accounts_test.exs:42`, walks the call path with lsp goToDefinition, and fixes the Elixir code rather than the assertion. To debug a single failing test in Elixir, run just that test in isolation and fix the code, not the assertion. Atlas runs the one test with its bash tool using ExUnit's line filter, for example `mix test test/my_app/accounts_test.exs:42`, so the output is small enough to reason about. Atlas then reads the test and the module it exercises, walks the call graph with the lsp tool's goToDefinition and findReferences operations, and only then edits. Because Atlas's bash tool is a real shell, every lever you would reach for by hand is available: an IO.inspect added temporarily, ExUnit's --trace flag for verbose output, or a fixed --seed to rule out ordering. ## Key takeaways - Isolate the failure first: `mix test test/my_app/accounts_test.exs:42` beats reading a whole ExUnit suite's output. - The lsp goToDefinition and findReferences operations walk the Elixir call path that a pipe-heavy assertion hides. - IO.inspect returns its argument, which makes it the idiomatic temporary probe inside an Elixir pipeline. - Fix the code, not the assertion; use apply_patch when the change spans several hunks in one module. - Re-run the single test, then the full `mix test` suite, then delete every temporary probe and run `mix format`. ## How do I run just one failing ExUnit test in Elixir? Run only the failing test with Atlas's bash tool using ExUnit's filter flag, so the output is small enough to reason about. `mix test test/my_app/accounts_test.exs:42` executes the single case at line 42, which turns hundreds of lines of suite output into one focused failure block. Isolation is the first move because the full ExUnit suite drowns the signal. A line-filtered `mix test` run in an Elixir project prints the failing assertion, the left and right values, and the stacktrace, and nothing else. Add ExUnit's --trace flag through bash when the failure is timing-related or when you need per-test output, and pass an explicit --seed when you suspect the failure only appears under a particular test ordering. All of it goes through the same bash tool, because bash is a real shell rather than a restricted command list. ## How do I find why one Elixir test fails without guessing? Atlas reads the failing ExUnit test and the module it exercises, then uses the lsp tool's goToDefinition and findReferences operations to walk the call path. An assertion failing in `test/my_app/accounts_test.exs` is rarely caused there; the fault is usually 2 or 3 calls deep in `lib/my_app/accounts.ex`. Elixir's pipe-heavy style makes call-path walking essential. A test asserting on the result of a pipeline through three functions gives no indication of which stage misbehaved. goToDefinition on each function in the pipe opens the real implementation, including the function head whose pattern match may no longer accept the shape being passed. findReferences on a suspect function shows who else calls it, which tells you whether the bug is local to this path or shared. Atlas indexes code by AST declarations using tree-sitter, so multiple clauses of the same Elixir function are distinct declarations rather than lines in a window. ## How do I test a hypothesis about a failing Elixir test? Form 1 hypothesis and check it before editing anything. Atlas adds temporary logging with the edit tool, typically an IO.inspect with a label piped into an Elixir pipeline, or re-runs `mix test` with a verbose flag through bash. A hypothesis you did not test is a guess, and Elixir pipelines hide the intermediate value that settles the question. IO.inspect is the idiomatic probe in Elixir precisely because it returns its argument, so it can be dropped into the middle of a pipe without changing the data flow. Inspecting the value between two stages of `lib/my_app/accounts.ex` shows exactly where the shape diverges from what the next function head expects. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so even a temporary probe is a reviewed change. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, which keeps `mix test` on allow while writes to `lib/` stay visible. ## Should I fix the Elixir code or change the assertion? Fix the Elixir production code with Atlas's edit tool, not the assertion. A failing ExUnit test poses 2 distinct questions, and only 1 of them is answered by editing `test/my_app/accounts_test.exs`. Changing an assertion to match broken behavior is how a suite stops being evidence; a genuinely wrong expectation deserves its own commit. When the change spans several hunks in the same Elixir module, use apply_patch instead of chaining brittle edits, because each successive edit shifts the content the next one is trying to match. Atlas snapshots file changes as git patches, so a fix to `lib/my_app/accounts.ex` that turns out to be wrong can be diffed and rolled back rather than hand-reverted. After the fix, run `mix format` so the patch carries logic rather than whitespace, and remember that Mix and Hex govern the dependency surface: if the bug came from a dep, the fix may belong in `mix.exs` rather than in your code. ## What do I do after the Elixir test passes again? Re-run the single test, then the full ExUnit suite, and remove any temporary logging you added. A fix that turns one `mix test` line filter green while breaking 6 other cases is not a fix, and an IO.inspect left behind in `lib/my_app/accounts.ex` becomes production noise the moment it ships. The two-stage re-run is deliberate. The line-filtered `mix test` run confirms the specific fix. The full `mix test` run confirms no collateral damage, which matters in Elixir because a changed function head can break every caller whose arguments no longer match. Grep the diff for IO.inspect before committing: temporary probes are the single most common leftover in Elixir debugging. Run `mix format` last, then review the whole change. Atlas reads git branches, status, and diffs, and can stage and create commits on your behalf once the suite is green. ## Steps 1. Run just the failing test with Atlas's bash tool using ExUnit's line filter, for example `mix test test/my_app/accounts_test.exs:42`, so the output is small enough to reason about. 2. Read the ExUnit test and the module it exercises, then use the lsp tool's goToDefinition and findReferences operations to walk the call path into `lib/my_app/accounts.ex`. 3. Check which function head is failing to match, since Elixir dispatches on pattern-matched clauses and a changed shape breaks the clause rather than the call. 4. Form a hypothesis and check it: add a temporary IO.inspect with the edit tool inside the pipeline, or re-run `mix test` with the --trace flag through bash. 5. Pass an explicit --seed to `mix test` if you suspect the failure only appears under a particular ExUnit ordering. 6. Fix the production code with the edit tool, not the assertion; use apply_patch instead of chained edits when the change spans several hunks. 7. Re-run the single line-filtered `mix test`, then the full ExUnit suite, to confirm the fix did not break other callers of the changed function head. 8. Remove every temporary IO.inspect you added, run `mix format`, and review the whole diff before committing. ## FAQ ### how to run a single failing test in elixir with atlas Use ExUnit's line filter through Atlas's bash tool: `mix test test/my_app/accounts_test.exs:42` runs only the case at line 42. The output is a single failure block rather than a whole suite, which is small enough to reason about directly. ### elixir test fails but the assertion looks right The fault is usually deeper than the assertion. Use the lsp tool's goToDefinition operation on each function in the pipeline to open the real implementation in `lib/`, and check whether a function head's pattern match no longer accepts the shape being passed. ### how do i debug an elixir pipeline mid-value Add an IO.inspect with a label inside the pipe. IO.inspect returns its argument, so it can sit between two stages without changing the data flow, and it shows exactly where the shape diverges from what the next function head expects. ### mix test --trace when to use it Run `mix test` with --trace through Atlas's bash tool when the failure is timing-related or when you need per-test output. Because Atlas's bash is a real shell, every ExUnit flag you would use by hand is available. ### should i change the test or the code when an elixir test fails Fix the production code. Changing an ExUnit assertion to match broken behavior stops the suite from being evidence. If the assertion genuinely encodes the wrong expectation, that is a separate decision and deserves its own commit. ### atlas apply_patch vs edit in elixir Use apply_patch when the fix spans several hunks in the same Elixir module. Chained edits are brittle, because each write shifts the content the next edit is trying to match. Atlas surfaces a unified diff for approval either way. ### elixir test only fails sometimes Suspect ExUnit's random ordering. Pass an explicit --seed to `mix test` through bash to reproduce the exact ordering that failed, which turns an intermittent failure into a deterministic one you can debug. ### how do i avoid leaving io.inspect in my elixir code Grep the diff for IO.inspect before committing. Temporary probes are the most common leftover in Elixir debugging, and they become production noise the moment they ship. Run `mix format` after removing them so the final patch is clean. --- Canonical HTML: https://runatlas.sh/resources/stacks/debug-a-failing-test-in-elixir Source of truth: aeo_pages row `/resources/stacks/debug-a-failing-test-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.