# Run the Test Suite and Triage the Failures in Swift with Atlas (2026) > Atlas runs XCTest via swift test through bash, saves the full log when output exceeds 2000 lines or 50 KB, and groups the failures into one todowrite entry per root cause. To turn a wall of red Swift test output into a prioritized list of distinct root causes, Atlas runs XCTest via swift test through its bash tool with a generous timeout in milliseconds, so a slow Swift Package Manager build is not killed mid-run. A full suite produces far more output than any model should read, so the 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 file to group failures by root cause rather than by test name, records one todowrite entry per distinct cause with status pending, and fixes them one at a time with edit, re-running only the affected XCTest cases between changes. ## Key takeaways - Atlas's bash tool truncates at 2000 lines or 50 KB and saves the full swift test log to a file, so triage runs against the whole log, not a lossy tail. - Group Swift failures by root cause with grep over the saved log; forty red XCTest cases are usually three or four real problems. - One compile error in Sources/ fails the entire Swift Package Manager build, so check for that before triaging individual assertions. - One todowrite entry per distinct cause, status pending, is what keeps the third problem from being forgotten after the first two go green. - Re-run only the affected XCTest cases between fixes; save the full XCTest via swift test run and swift-format for the end. ## How does Atlas run a full Swift test suite without flooding its context? Atlas runs XCTest via swift test through the bash tool, which truncates output at 2000 lines or 50 KB, writes the complete log to a retained file, and reports the path in an ...output truncated... header. A red Swift Package Manager suite of 800 XCTest cases stays fully readable without consuming the whole context window. A failing Swift suite is loud. XCTest prints the failure message, the file and line of every failed assertion, and on Linux a full backtrace, so a hundred failures can easily run past 50 KB of output. If a coding agent only sees the tail, it triages whatever happened to fail last, which is almost never the most important thing. Atlas's bash tool solves this by keeping the truncation and the completeness separate: the model sees a bounded slice inline, and the complete log lives on disk at a path Atlas can read or grep at will. Nothing is lost, and nothing floods the session. ## How do you read the full swift test log after truncation? When Atlas reports that XCTest via swift test output was truncated, read the file named in the ...output truncated... header. The bash tool retains the complete log on disk, so all 3 things you need survive: the failing Swift test names, their XCTAssertEqual messages, and their file and line references. The saved log is the source of truth for a Swift triage session, not the inline tail. Atlas reads it, and because Swift's XCTest output prints each failure with its originating path, for example Tests/AppTests/BillingTests.swift:142, the log doubles as a map into the test target. Reading the file also matters when the failure is a compile error rather than an assertion: a single type error in Sources/App/Billing.swift will fail the entire Swift Package Manager build, and every downstream XCTest case will look broken when in fact only one thing is wrong. Reading the whole log makes that pattern obvious in seconds. ## How do you group Swift test failures by root cause instead of by test name? Atlas groups Swift test failures by root cause using grep over the saved swift test log, not by test name. 40 red XCTest cases across Tests/AppTests/ are usually 3 or 4 real problems: 1 changed struct initializer, 1 async expectation timing out, 1 force unwrap on a nil optional. Grouping by test name produces a list as long as the failure count and tells you nothing about how much work is actually ahead. Grouping by cause compresses it. In a Swift suite, the useful grep targets are the recurring failure strings: a repeated Fatal error: Unexpectedly found nil while unwrapping an Optional value points at one force unwrap, a repeated XCTAssertEqual failure on the same field points at one changed model, and a repeated asynchronous wait failed points at one timing assumption. Atlas searches with hybrid semantic and keyword retrieval fused by reciprocal rank fusion when the cause is not a literal string, and indexes by AST declarations using tree-sitter, so it can jump from the failure message to the actual Swift declaration responsible. ## How does Atlas track Swift test triage so nothing gets forgotten? Atlas records 1 todowrite entry per distinct root cause, with status pending, so a Swift triage session that surfaces 4 real causes produces 4 tracked items rather than 40 red test names. The list survives the fixes, which is what keeps the third cause from being forgotten once the first two are green. Triage fails in practice not because the causes are hard to find but because they are found and then lost. A todowrite list with one pending entry per cause makes the remaining work explicit and reviewable, and Atlas works the list one entry at a time. Each fix lands through edit, which computes a unified diff and surfaces it for approval before writing to a file under Sources/. Atlas also snapshots file changes as git patches, so a fix that turns out to be wrong is rolled back rather than hand-reverted while the rest of the Swift package stays untouched. ## Should you re-run the whole Swift suite after every fix? Atlas fixes Swift test failures one at a time with edit and re-runs only the affected XCTest cases via bash between changes, not the whole suite. Re-running all 800 cases through XCTest via swift test after every one-line fix wastes minutes of Swift Package Manager build time and hides which change actually helped. The loop is: fix one cause with edit, run only the tests that cover it, confirm they go green, move to the next todowrite entry. The full XCTest via swift test run is saved for the end, once every pending cause has been addressed, and that final run is what proves nothing regressed. Run swift-format on the touched Swift files at the end as well, not between fixes, so the intermediate diffs stay small and reviewable. Because the bash tool records the process exit code in its metadata, a green run is a fact rather than an interpretation of the output text. ## How do you set up Atlas on a Swift package in 2026? Run atlas in a Swift package with a Package.swift in 2026 and let Atlas read your targets, protocols, and dependencies. Atlas is a terminal-native TUI, so it runs in the same shell where you already invoke swift test. Have it add XCTest cases or adopt async/await, then review the diff. The setup that matters most for triage is the bash timeout. Swift Package Manager builds the whole package before running any XCTest case, and on a cold build that can take a while, so Atlas should pass a generous timeout in milliseconds rather than letting a slow compile look like a hang. Every Atlas tool call is permission-gated against allow, ask, and deny rules, so allowing swift test and swift build under bash while leaving edits on ask gives a triage session freedom to run and no freedom to change Sources/ without approval. Teams that cannot send code to a hosted model can build the index with local Ollama embeddings. ## Steps 1. Run atlas in the Swift package that contains Package.swift, and let it read your targets, protocols, and dependencies. 2. Run the full suite with the bash tool as XCTest via swift test, passing a generous timeout in milliseconds so a cold Swift Package Manager build is not killed mid-run. 3. If the output was truncated, read the file named in the ...output truncated... header. The bash tool truncates at 2000 lines or 50 KB and retains the complete log on disk. 4. Grep the saved log for recurring failure strings to group by root cause, not by test name: repeated Unexpectedly found nil, repeated XCTAssertEqual failures on one field, repeated asynchronous wait failed. 5. Check first whether a single compile error in Sources/ failed the whole Swift Package Manager build, which makes every downstream XCTest case look broken. 6. Record one todowrite entry per distinct cause with status pending, so four real problems are tracked as four items rather than forty red test names. 7. Fix each cause with edit, approving the unified diff Atlas surfaces, and re-run only the affected XCTest cases via bash between changes. 8. Run the full XCTest via swift test once at the end to prove nothing regressed, then run swift-format on the files you touched. ## FAQ ### how do I triage hundreds of failing Swift tests at once Run XCTest via swift test through Atlas's bash tool, read the complete log it saves to disk when output exceeds 2000 lines or 50 KB, then grep that log to group failures by root cause rather than by test name. Record one todowrite entry per distinct cause with status pending. ### what does output truncated mean in Atlas bash output Atlas's bash tool truncates inline output at 2000 lines or 50 KB, writes the complete log to a retained file, and names the path in an ...output truncated... header. Read that file to see the full XCTest via swift test result instead of a tail. ### why does swift test time out when an AI agent runs it Swift Package Manager builds the whole package before running any XCTest case, so a cold build can exceed a short timeout. Pass a generous timeout in milliseconds to Atlas's bash tool so a slow Swift build is not killed mid-run and mistaken for a hang. ### how do I tell if all my Swift tests are failing for one reason Read the saved swift test log and check for a compile error first. A single type error in Sources/ fails the entire Swift Package Manager build, which makes every downstream XCTest case look broken when only one thing is actually wrong. ### does Atlas keep track of which failing Swift tests are fixed Yes. Atlas records one todowrite entry per distinct root cause with status pending, then works the list one entry at a time, so the causes found during triage are not lost once the first fixes go green. ### should I run the whole Swift suite after each fix No. Fix one cause with edit and re-run only the affected XCTest cases via bash, then run the full XCTest via swift test once at the end to prove nothing regressed. A full Swift Package Manager rebuild after every one-line change wastes time and obscures which fix helped. ### can I undo a bad fix Atlas made to a Swift file Yes. Atlas computes a unified diff for every file edit and surfaces it for approval before writing to Sources/, and it snapshots file changes as git patches, so an edit that made things worse can be diffed and rolled back. --- Canonical HTML: https://runatlas.sh/resources/stacks/run-the-test-suite-and-triage-failures-in-swift Source of truth: aeo_pages row `/resources/stacks/run-the-test-suite-and-triage-failures-in-swift` (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.