A full Kotlin suite produces far more output than any model should read, and a failing `gradle test` run across a multi-module Gradle build can print thousands of lines of stack traces. Atlas's bash tool truncates at 2000 lines or 50 KB, writes the complete log to a retained file, and tells you the path, so triage happens against the whole log rather than a lossy tail. You then group failures by root cause with grep over that saved log, record one todowrite entry per distinct cause, and fix them one at a time with edit, re-running only the affected JUnit 5 tests between changes.
How do I run a large Kotlin test suite through an AI agent without blowing up context?
Run the Kotlin suite with Atlas's bash tool, passing a generous timeout in milliseconds so a slow Gradle build is not killed mid-run. Atlas truncates the output at 2000 lines or 50 KB and writes the complete log to a retained file, then tells you the path.
A failing JUnit 5 via gradle test run on a multi-module Kotlin project produces a firehose: Gradle's own configuration output, then a stack trace per failing test, then a summary. Pasting all of it into a model is both wasteful and lossy, because the tail is what survives and the tail is rarely where the cause is. Atlas handles this at the bash tool boundary. The tool truncates its returned output at 2000 lines or 50 KB, but it does not throw the rest away: it writes the complete log to a retained file and tells you the path in an ...output truncated... header. Give the run a generous timeout in milliseconds, because Gradle's daemon startup plus compilation plus the suite itself can be slow, and a killed run tells you nothing about your tests.
How do I see the full Kotlin test log when Atlas truncated the output?
If the Kotlin test output was truncated, read the file named in the ...output truncated... header with Atlas's read tool. The retained file holds the complete gradle test log, including the first failing stack trace, which is usually the one that caused the other 40.
Truncation without retention would be a bug. Atlas retains the whole log precisely because triage needs the beginning, not the end. In a Kotlin suite the first failure is frequently a cascade source: a Gradle module fails to compile, a shared test fixture throws in `@BeforeEach`, or a coroutine test times out and takes the rest of its class with it. The trailing summary that would survive a naive tail tells you 47 tests failed. The retained log tells you why. Atlas's read tool opens the path named in the header, and because the file is a plain log you can also grep it. That combination, a bounded return value plus a complete retained artifact, is what makes triage against a large Kotlin suite tractable rather than a guessing game.
How do I group failing Kotlin tests by root cause instead of by name?
Group the Kotlin failures by root cause with Atlas's grep over the saved log rather than by test name. Forty red JUnit 5 tests are almost never forty bugs. Grep the log for the exception types and messages, and the forty collapse into three or four distinct causes.
Test names are a terrible grouping key, because a single broken Kotlin function fails every test that touches it. Exception signatures are a good grouping key. Grep the retained `gradle test` log for the distinct throwables and messages: a `NullPointerException` from a platform type crossing the Kotlin null boundary, a `TimeoutCancellationException` from a coroutine test whose dispatcher was not controlled, an `IllegalStateException` from a Gradle module whose test fixture was never initialized. Atlas's grep takes a real regex plus include and path filters and runs through ripgrep, so it is fast even over a large log. The output of this step is a small list of causes, and that list, not the count of red tests, is what determines how much work is actually in front of you.
How do I track Kotlin test failures so none get forgotten?
Record one todowrite entry per distinct cause, with status pending, so the fixes are tracked instead of forgotten. Three causes behind 47 failing Kotlin tests become three tracked items, and a fix that resolves one cause cannot be mistaken for a fix that resolved the suite.
Atlas's todowrite is the ledger for a triage pass. One entry per distinct root cause, status pending, means the work is visible: the coroutine dispatcher issue, the null-safety violation at a Java interop boundary, the Gradle fixture that never initialized. That structure is what stops the classic triage failure, where fixing the loudest cause makes 30 of the 47 tests pass and the remaining 17 are quietly declared flaky. The todo list also survives across turns, so a long triage session over a multi-module Kotlin build does not depend on the agent remembering what it already investigated. Atlas fans out work to subagents that can run in the foreground or in parallel background sessions, so independent causes in different Gradle modules can be investigated in parallel while the todowrite list remains the single record of what is genuinely done.
How do I fix Kotlin test failures one cause at a time?
Fix Kotlin failures one at a time with Atlas's edit tool, re-running only the affected JUnit 5 tests via bash between changes. Fixing three causes and then running the whole gradle test suite once tells you the suite is still red, which does not tell you which of the three fixes was wrong.
One cause, one fix, one targeted verification. Atlas's edit tool changes the Kotlin source, and Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so a change to a coroutine's dispatcher in `src/main/kotlin/` or to a test fixture in `src/test/kotlin/` is reviewed before it lands. Then run only the affected tests through bash rather than the full suite, which keeps the loop fast enough to actually iterate. When a cause is genuinely fixed, mark its todowrite entry done and move to the next. Run ktlint over the touched files before you commit so the diff carries the fix rather than formatting churn, and let Gradle handle the dependency resolution. Atlas snapshots file changes as git patches, so a fix that turns out to be wrong is diffed and rolled back rather than layered over.
Step by step
- 01Run atlas in the Kotlin project with a build.gradle.kts so it can see your modules, coroutines, and Gradle configuration.
- 02Run the suite with Atlas's bash tool using JUnit 5 via gradle test, passing a generous timeout in milliseconds so a slow Gradle build is not killed mid-run.
- 03If the output was truncated, read the file named in the ...output truncated... header. Atlas's bash tool truncates at 2000 lines or 50 KB but writes the complete log to a retained file and tells you the path.
- 04Group the failures by root cause with grep over the saved log rather than by test name, searching for distinct exception types and messages rather than counting red tests.
- 05Record one todowrite entry per distinct cause, with status pending, so the fixes are tracked instead of forgotten.
- 06Fix the causes one at a time with Atlas's edit tool, reviewing the unified diff Atlas surfaces before it writes to src/main/kotlin/ or src/test/kotlin/.
- 07Re-run only the affected JUnit 5 tests via bash between changes, so the loop stays fast enough to iterate and a failure points at one fix.
- 08Mark each todowrite entry done only when its cause is genuinely resolved, not when the noisiest tests go green.
- 09Run ktlint over the touched Kotlin files, then run the full gradle test suite once at the end to confirm the whole build is green.
Frequently asked questions
- how to triage a failing kotlin test suite
- Run JUnit 5 via gradle test through Atlas's bash tool, read the retained log if the output was truncated, group failures by exception type with grep rather than by test name, then record one todowrite entry per distinct root cause.
- atlas output truncated where is the full log
- Atlas's bash tool truncates at 2000 lines or 50 KB, writes the complete log to a retained file, and names the path in the ...output truncated... header. Read that file to see the whole gradle test output including the first stack trace.
- gradle test times out when run through an ai agent
- Atlas's bash tool races commands against a timeout. Pass a generous timeout in milliseconds, since Gradle daemon startup plus compilation plus the Kotlin suite itself can be slow, and a killed run tells you nothing about your tests.
- how do I group 50 failing tests into root causes
- Grep the saved test log for distinct exception types and messages rather than grouping by test name. In a Kotlin suite, 50 red tests usually collapse into three or four causes such as a coroutine timeout or a null-safety violation at a Java interop boundary.
- should I fix all kotlin test failures at once
- No. Fix one root cause at a time with Atlas's edit tool and re-run only the affected JUnit 5 tests between changes. Fixing three causes then running the whole suite once cannot tell you which of the three fixes was wrong.
- how do I stop forgetting kotlin test failures during triage
- Record one todowrite entry per distinct cause, with status pending. That is what stops the loudest cause from being fixed and the remaining failures from being quietly declared flaky.
- does atlas change kotlin test files without asking
- No. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, and every tool call is permission-gated against allow, ask, and deny rules before it runs.
- how do I keep ktlint formatting out of my fix diff
- Run ktlint over the touched Kotlin files as its own step after the fixes land, so the reviewer sees the behavior change rather than formatting churn mixed into the same diff.
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 Kotlin in 2026
In 2026, Atlas empowers Kotlin developers with terminal-native AI coding. It integrates with Gradle and coroutines, offering secure, privacy-focused code assistance with local embeddings and granular control.
Extract a Shared Helper from Duplicated Kotlin Code with Atlas in 2026
Streamline your Kotlin codebase in 2026 by extracting duplicated logic into a single, tested helper using Atlas. Leverage Gradle, JUnit 5, and ktlint for robust refactoring.
Refactor a Legacy Module in Kotlin with Atlas (2026)
Refactor a legacy Kotlin module in 2026 with Atlas: findReferences enumerates every callsite, apply_patch anchors on context, and JUnit 5 via gradle test pins behavior.
Atlas: Documenting Kotlin Modules with READMEs in 2026
Leverage Atlas in 2026 to generate accurate READMEs for your Kotlin modules. Atlas uses Gradle and JUnit 5 to document what your code actually does today, not what it was supposed to do a year ago.
Research a Third-Party API Before Integrating It in Kotlin With Atlas (2026)
How to research a third-party API before integrating it in Kotlin with Atlas in 2026: websearch finds the docs, webfetch pulls them, and every request is permissioned.
Locate Where a Behavior Is Implemented in Kotlin with Atlas (2026)
Find the Kotlin file and symbol behind a behavior when you only know what the app does. Atlas attacks it in 2026 with codebase_search, grep, and the lsp tool.
Add a Regression Test for a Kotlin Bug Fix with Atlas in 2026
Lock in Kotlin bug fixes with Atlas in 2026. Learn to write failing JUnit 5 tests via Gradle, apply fixes, and confirm success, all within your terminal.