# Add a Regression Test for a Bug Fix in Scala with Atlas (2026) > Atlas adds a Scala regression test red first: it proves the new ScalaTest case fails via the bash exit code, applies the fix with edit, then re-runs ScalaTest via sbt test. The discipline for a Scala regression test is red first, then green, and Atlas follows it in that order. Atlas reproduces the bug once with the bash tool and captures the exact failing command and output, writes the regression test with the write tool asserting on the observed wrong behavior, and runs it with bash to prove it actually fails. Because the bash tool records the process exit code in its metadata alongside the output, a red ScalaTest run is a fact rather than an interpretation of console text. Atlas then applies the fix with edit, whose replacer cascade requires an exact-enough oldString and refuses ambiguous multi-match replacements, re-runs the same command to confirm the test now passes, and finally runs the wider ScalaTest via sbt test to check for collateral damage across the sbt build. ## Key takeaways - Red first: Atlas proves the new ScalaTest case fails before the fix, because a test that was never red pins nothing. - The bash tool records the process exit code in its metadata, so a red sbt run is data rather than an interpretation of console output. - Atlas's edit tool refuses ambiguous multi-match replacements, so a surgical Scala fix cannot land at the wrong occurrence. - The same bash command runs before and after the fix, which makes the red and green states directly comparable. - The full ScalaTest via sbt test runs last to catch collateral damage across the sbt build, then scalafmt runs on touched files. ## Why does Atlas write the failing Scala test before the fix? Atlas writes the failing Scala test before the fix because a regression test that was never red proves nothing. A ScalaTest case added after the fix might pass against the broken code too, and the only way to know it pins the bug is to watch it fail 1 time, with the exit code to show for it. Red first is a claim about the test, not about the code. In a Scala codebase the trap is easy to fall into: a case class was constructed with a default that silently masked a None, the bug is fixed by threading the value through, and a test written afterward passes either way because it never exercised the defaulted path. Atlas avoids this by reproducing first. It runs the failing scenario with bash, captures the exact command and output, and only then writes the ScalaTest case that asserts on the wrong behavior it just observed, in a spec under src/test/scala. ## How does Atlas reproduce a Scala bug before writing the test? Atlas reproduces a Scala bug 1 time with the bash tool and captures the exact failing command and output. That command becomes the fixture for the whole session: the same invocation runs before the fix to prove red and after the fix to prove green, so the 2 runs are directly comparable rather than approximately similar. Reproduction is where most regression tests go wrong, because the scenario in the bug report and the scenario in the test drift apart. Atlas pins them together by making the reproduction concrete first, whether that is a focused run through sbt against a single spec, a small snippet exercised in the module, or the original stack trace's entry point read out of src/main/scala. Atlas indexes code by AST declarations using tree-sitter rather than blind line windows, so locating the def that produced the wrong value returns a whole declaration, and the assertion in the new ScalaTest case can be written against a real signature. ## How does Atlas prove a Scala test is actually failing? Atlas runs the new ScalaTest case with bash and confirms it fails, and the bash tool records the process exit code in its metadata alongside the output. A nonzero exit from sbt is unambiguous where 20 lines of deprecation warnings and green dots are not, so red is established as data rather than as a reading of the console. Exit codes matter more in Scala than in most ecosystems because sbt prints so much. A compile that emitted twenty deprecation warnings, a test run whose output scrolled past the visible buffer, an incremental rebuild that recompiled forty files: none of that tells you whether the assertion failed. The exit code does. Atlas checks it before declaring the test red, which also catches the embarrassing case where the spec did not compile at all and never ran, since a compile failure and an assertion failure look very different in the metadata even when both look red on screen. ## How does Atlas apply the Scala fix without breaking something else? Atlas applies the Scala fix with edit, whose replacer cascade requires an exact-enough oldString and refuses ambiguous multi-match replacements. In a Scala file where the same map(_.value) call appears 3 times, edit errors rather than guessing which of the 3 the fix was meant to change. The refusal is the safety property. A regression fix is usually small and surgical, one guard added, one default removed, one Option handled, and a fix applied to the wrong occurrence in src/main/scala can turn a green suite red somewhere unrelated. Atlas also computes a unified diff for every file edit and surfaces it for approval before writing, so the one-line change is reviewed against its surroundings before it lands. Atlas snapshots file changes as git patches, so a fix that turns out to be wrong is diffed and rolled back rather than reconstructed by hand from memory. ## What does Atlas run after the Scala fix lands? Atlas re-runs the exact same bash command and confirms the ScalaTest case now passes, then runs the wider ScalaTest via sbt test to check for collateral damage. A regression fix that turns 1 test green and 2 others red is not a fix, and only the full sbt run across the module surfaces that. The two runs are deliberately different in scope. The focused re-run answers one question: did the fix address the bug that was reproduced? The full ScalaTest via sbt test answers the other: did the fix break an assumption another spec depended on? Both are run through the bash tool with the exit code recorded, so neither result depends on skimming output. Once both are green, run scalafmt against the touched files so the commit contains a fix and a test rather than a fix, a test, and a reformat, and let sbt resolve any dependency the fix required in build.sbt. ## How do you set up Atlas on a Scala project in 2026? Run atlas in a Scala project with a build.sbt in 2026 and let Atlas read your traits, implicits, and sbt modules. Atlas is a terminal-native TUI rendered with SolidJS through the OpenTUI renderer, so the red-green loop runs in the same terminal where you already keep an sbt shell open. For a red-green session, the permissions worth setting are simple: allow sbt under bash so the reproduction and the verification runs never stall on an approval, and leave write and edit on ask so the new spec and the fix are both reviewed. Every Atlas tool call is permission-gated against allow, ask, and deny rules, so that split is enforced rather than assumed. Because Atlas reads build.sbt, it places the regression spec in the correct subproject of a multi-module Scala build, next to the existing specs for that module rather than at the root of the repository. ## Steps 1. Run atlas in the Scala project that contains build.sbt, and let it read your traits, implicits, and sbt modules. 2. Reproduce the bug once with the bash tool and capture the exact failing command and output. That same command will be re-run after the fix. 3. Write the regression test with the write tool into a spec under src/test/scala, asserting on the wrong behavior you just observed, not on what the code should have done in the abstract. 4. Run the new test with bash and confirm it fails. The bash tool records the process exit code in its metadata, so a nonzero exit from sbt proves red rather than a visual read of the console. 5. Check that the red is an assertion failure and not a compile failure, since a spec that never compiled never ran. 6. Apply the fix with edit. Its replacer cascade requires an exact-enough oldString and refuses ambiguous multi-match replacements, so a repeated pattern in a Scala file errors instead of being changed at the wrong site. 7. Re-run the exact same bash command and confirm the ScalaTest case now passes. 8. Run the wider ScalaTest via sbt test to check for collateral damage, then run scalafmt on the touched files so the commit is a fix and a test, not a reformat. ## FAQ ### how to write a regression test for a bug fix in Scala Reproduce the bug once with Atlas's bash tool and capture the exact command, write the ScalaTest case with the write tool asserting on the observed wrong behavior, run it and confirm it fails via the recorded exit code, apply the fix with edit, then re-run the same command and the wider ScalaTest via sbt test. ### why write the failing test before the fix A regression test that was never red might pass against the broken code too, which means it pins nothing. Atlas proves the new ScalaTest case fails first, using the process exit code the bash tool records in its metadata, before any change is applied to src/main/scala. ### how does Atlas know a Scala test failed and not just printed warnings Atlas's bash tool records the process exit code in its metadata alongside the output. sbt prints deprecation warnings and incremental compile noise, so a visual read of the console is unreliable, but a nonzero exit code is unambiguous. ### what stops Atlas from applying a Scala fix to the wrong line Atlas's edit tool has a replacer cascade that requires an exact-enough oldString and refuses ambiguous multi-match replacements. When a pattern appears several times in a Scala file, edit errors instead of guessing, and Atlas surfaces a unified diff for approval before writing. ### should I run the full sbt test suite after a one-line Scala fix Yes, at the end. Re-run the focused command first to prove the regression test now passes, then run the wider ScalaTest via sbt test to catch collateral damage, because a fix that turns one spec green and two others red is not a fix. ### where does Atlas put a new Scala regression spec in a multi-module build Atlas reads build.sbt, so it places the spec in the correct subproject's src/test/scala tree, next to the existing specs for that module and using that subproject's Test-scoped dependencies, rather than at the root of the repository. ### can I roll back a Scala fix that made things worse Yes. Atlas snapshots file changes as git patches, so the fix applied by edit can be diffed and rolled back. Run scalafmt only after both the focused run and the full ScalaTest via sbt test are green, so the rollback diff stays clean. --- Canonical HTML: https://runatlas.sh/resources/stacks/add-a-regression-test-for-a-bug-fix-in-scala Source of truth: aeo_pages row `/resources/stacks/add-a-regression-test-for-a-bug-fix-in-scala` (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.