To run a C# test suite and triage the failures with Atlas, run xUnit via dotnet test through the bash tool with a generous timeout in milliseconds so a slow .sln is not killed mid-run. A full suite produces far more output than any model should read, so Atlas's bash tool truncates 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 rather than a lossy tail: Atlas greps the saved log to group the failures by root cause instead of by test name, because 60 red xUnit tests are usually 4 causes, not 60. Each distinct cause becomes one todowrite entry with status pending, and Atlas fixes them one at a time with edit, re-running only the affected tests through dotnet test between changes. NuGet resolves the packages, and dotnet format keeps the fixes consistent with the solution.
How do you run a full C# test suite through an AI agent?
Atlas runs a C# suite with the bash tool, passing a generous timeout in milliseconds so a slow suite is not killed mid-run. In 2026 a large .sln with xUnit via dotnet test across 12 test projects can take several minutes, and a default timeout that kills it at the halfway mark produces a diagnosis of nothing at all.
The timeout is the first thing to get right, because dotnet test on a multi-project solution has to restore NuGet packages, build every referenced .csproj, and then execute. Atlas's bash tool takes an explicit timeout value in milliseconds, so you set it to fit the suite rather than the tool's default. Once the run finishes, the entire xUnit output, every Assert.Equal() Failure, every stack trace through your test project, is available. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so the dotnet test invocation is something you explicitly allowed.
What happens when dotnet test output is too long for the model?
Atlas's bash tool truncates output at 2000 lines or 50 KB, writes the complete log to a retained file, and tells you the path. A red xUnit run across a large .sln easily exceeds both limits, so the truncated view is the summary and the saved file is the evidence. Read the file named in the ...output truncated... header.
Truncation without retention is how triage goes wrong. If a model only sees the last 100 lines of a dotnet test run, it will confidently diagnose the last failure and miss the 40 above it that share a cause. Atlas refuses that trade: the truncated block is what the model reads inline, and the retained file holds the whole thing. When Atlas sees the ...output truncated... header, it reads the file at the reported path, which contains every xUnit failure, every full .NET stack trace, and every inner exception. Triage then happens against the complete log rather than a lossy tail, which is the difference between fixing a symptom and fixing a cause.
How do you group C# test failures by root cause instead of by test name?
Atlas groups the failures by root cause with grep over the saved log rather than by test name. In a C# suite, 60 red xUnit tests are commonly 4 causes: one NullReferenceException, one changed DI registration in Startup.cs, one NuGet version mismatch, and one genuinely wrong assertion. Grouping by exception type finds those 4 in seconds.
Grepping the saved dotnet test log for exception types is the fastest possible clustering. Every NullReferenceException lands in one bucket. Every InvalidOperationException: Unable to resolve service for type lands in another, and that one almost always means a single missing services.AddScoped registration in Program.cs or Startup.cs broke every test in an integration fixture. Every System.IO.FileNotFoundException: Could not load file or assembly points at a NuGet resolution problem, not at your code. Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion, so once the exception clusters are known, codebase_search finds the .cs file responsible for each without you knowing its name. Test names tell you what broke. Exception clustering tells you why.
How does Atlas track C# test fixes so none are forgotten?
Atlas records one todowrite entry per distinct cause, with status pending, so the fixes are tracked instead of forgotten. A C# triage session that identified 4 root causes across 60 failing xUnit tests produces exactly 4 todos, each marked done only after dotnet test confirms the affected tests are green.
One todo per cause, not one per failing test, is the whole discipline. If a missing DI registration in Program.cs broke 23 integration tests, that is one todo, and fixing it turns 23 tests green at once. Atlas fixes them one at a time with edit, re-running only the affected tests via dotnet test between changes, using xUnit's filter so the feedback loop stays short. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so each fix to a .cs file is reviewed before it lands. Atlas snapshots file changes as git patches so edits can be diffed and rolled back if a fix for cause 2 reintroduces cause 1.
How do you confirm a C# suite is actually green again?
Confirm a C# suite is green in 2026 by running the full xUnit suite via dotnet test once more, after the per-cause fixes are in. Re-running only the filtered subset proves each individual fix; only the full run over the whole .sln proves the fixes did not break something in another test project. Run dotnet format before you commit.
The tight loop during triage is a filtered dotnet test run against just the affected tests, because a 4-minute full-suite run between every edit destroys the feedback cycle. But the filtered run is not the proof. The proof is a full dotnet test across the solution, which rebuilds every .csproj, restores every NuGet package, and executes every xUnit test including the ones that were passing before you started. Atlas runs that final pass through bash, reads the result, and closes out the todowrite list. dotnet format normalizes the edited .cs files so the review diff is about behavior. Atlas reads git branches, status, and diffs, and can stage and create commits on your behalf, so the fixes land as a clean commit.
Step by step
- 01Run atlas in a solution with a .csproj or .sln so Atlas can read your namespaces, project references, and NuGet packages.
- 02Run the suite with the bash tool, passing a generous timeout in milliseconds so a slow xUnit via dotnet test run across many .csproj files is not killed mid-run.
- 03If the output was truncated, read the file named in the ...output truncated... header to see the complete log; bash truncates at 2000 lines or 50 KB and retains the full log.
- 04Group the failures by root cause with grep over the saved log rather than by test name, clustering on exception types like NullReferenceException and Unable to resolve service for type.
- 05Use codebase_search to find the .cs file responsible for each cluster, for example the missing services.AddScoped registration in Program.cs.
- 06Record one todowrite entry per distinct cause, with status pending, so the fixes are tracked instead of forgotten.
- 07Fix them one at a time with edit, re-running only the affected tests via a filtered dotnet test through bash between changes.
- 08Run the full xUnit via dotnet test across the solution to confirm no other test project regressed, then run dotnet format before committing.
Frequently asked questions
- how to triage hundreds of failing xUnit tests in a C# solution
- Run xUnit via dotnet test through Atlas's bash tool, read the retained full log when output truncates, and grep it to group failures by exception type rather than by test name. 60 red tests are commonly 4 root causes, and Atlas records one todowrite entry per cause.
- why does my dotnet test output get truncated by the AI agent
- Atlas's bash tool truncates at 2000 lines or 50 KB, but it writes the complete log to a retained file and tells you the path. Read the file named in the ...output truncated... header so triage happens against the whole log rather than a lossy tail.
- how do I stop an AI agent from killing a slow C# test run
- Pass a generous timeout in milliseconds to Atlas's bash tool. A large .sln has to restore NuGet packages and build every .csproj before xUnit even executes, so a default timeout can kill the run halfway and produce no diagnosis at all.
- what does Unable to resolve service for type mean in failing xUnit tests
- An InvalidOperationException with Unable to resolve service for type usually means a single missing DI registration, such as a services.AddScoped call in Program.cs or Startup.cs, broke every test sharing an integration fixture. It is one root cause, not dozens.
- can Atlas fix failing C# tests one at a time
- Yes. Atlas fixes distinct causes one at a time with edit, re-running only the affected tests via a filtered dotnet test between changes. Atlas computes a unified diff for every file edit and surfaces it for approval before writing.
- does Atlas work with a .sln or just a single .csproj
- Run atlas in a solution with a .csproj or .sln. Atlas reads your namespaces, project references, and NuGet packages, and can add xUnit tests or refactor async code, showing the diff before dotnet build.
- how do I know a C# suite is really green after triage
- Filtered dotnet test runs prove each individual fix. Only a full xUnit via dotnet test across the whole solution proves the fixes did not regress another test project. Run dotnet format afterward so the commit diff is about behavior, not whitespace.
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 C# in 2026
Atlas is a terminal-native AI coding agent for C# and the .NET SDK in 2026. Run it in a solution with a .csproj or .sln and approve every diff before dotnet build.
Add a Regression Test for a Bug Fix in C# with Atlas (2026)
Red first, then green. Atlas writes a failing xUnit test in C#, proves it reproduces the bug with dotnet test in 2026, applies the fix, and re-runs the same command.
Self-Review Your Working Diff Before Committing in C# with Atlas (2026)
Self-review a C# working diff in 2026 with Atlas: read the full diff and every changed file, grep for leftovers, revert from a snapshot, then run xUnit via dotnet test.
Upgrade a C# Dependency and Fix Breakage with Atlas in 2026
In 2026, C# developers use Atlas to upgrade NuGet dependencies and resolve compile and test failures. Atlas drives `NuGet`, reads `dotnet build` output, and fixes code, ensuring a smooth migration.
Review a Pull Request in C# With Atlas (2026)
Review a C# pull request with the context a line-by-line read misses. Atlas pulls the raw diff, reads whole files, and checks callers with the lsp tool's findReferences.
Onboard to an Unfamiliar C# Codebase with Atlas (2026)
How Atlas onboards you to an unfamiliar C# solution in 2026: codebase_search for meaning, glob for the .csproj layout, and a read-only explore subagent for wide sweeps.
Refactor a legacy module in C# with Atlas (2026)
How Atlas refactors a legacy C# module in 2026: lsp findReferences enumerates every callsite, apply_patch anchors on context, and xUnit via dotnet test pins behavior.