# Add a Regression Test for a Bug Fix in Go with Atlas (2026)

> Atlas locks in a Go bug fix by proving a new TestXxx fails under go test -run first, then applying the fix with edit and re-running the identical go test command.

Atlas adds a regression test for a Go bug fix by proving the test fails before the fix exists. Atlas reproduces the bug with the bash tool, writes a func TestXxx(t *testing.T) into a _test.go file with the write tool, runs go test -run TestXxx to confirm it fails, applies the fix with edit, then re-runs the identical go test command. The bash tool records the process exit code in its metadata alongside the output, so a red Go test and a green one are distinguished by a number, not by reading prose.

## Key takeaways

- Red first: Atlas requires a non-zero exit code from go test -run before it writes any fix, so a vacuous Go test never gets committed.
- The bash tool records the process exit code in its metadata, so a failing go test run is a number, not a guess from the output text.
- The edit tool's replacer cascade refuses ambiguous multi-match replacements, which stops a patch from landing on the wrong if err != nil block.
- Run the narrow go test -run command to prove the fix, then go test ./... to catch collateral damage across the module.
- Atlas computes a unified diff for every file edit and surfaces it for approval before writing, and snapshots file changes as git patches for rollback.
- Run gofmt on the new _test.go and the patched file so the commit carries no formatting noise.

## Why does a Go regression test have to fail first?

A Go regression test that has never failed proves nothing. Atlas runs the new TestXxx with go test -run before writing any fix, and requires an exit code other than 0 from that run. The bash tool records the process exit code in its metadata alongside the output, so red is a fact rather than an impression.

Red first, then green, is the whole discipline. In a Go module the trap is easy to fall into: you write a table-driven case, it passes immediately because the input never reaches the broken branch, and you ship a test that guards nothing. The exit code settles it. go test exits non-zero when a test fails, and Atlas reads that code from the bash metadata instead of pattern-matching the word FAIL out of the output. Atlas tools this workflow uses are bash, write, edit, and read, and the job is to lock in a fix with a test that fails before the change and passes after it.

## How does Atlas reproduce a Go bug before writing the test?

Atlas reproduces the Go bug once with the bash tool and captures 2 things: the exact failing command and its full output. In a go.mod module that is usually go test ./internal/billing, or go run ./cmd/api followed by the request that triggers the panic.

Reproduction is evidence gathering, not ceremony. The output of the reproducing command becomes the assertion target: Atlas asserts on the observed wrong behavior, using the concrete values Go actually printed rather than the values you believe it should have printed. A Go panic gives you a goroutine stack and a line number. A wrong return value gives you the got and want pair that a table-driven test will encode directly. Atlas captures both the command and the output verbatim, so the regression test written in the next step is anchored to something that really happened in your module.

## How do you write a failing Go regression test with Atlas?

Atlas writes the regression test with the write tool, asserting on the observed wrong behavior. In Go the test lands as a func TestXxx(t *testing.T) in a _test.go file beside the code, named after the issue, for example func TestDiscountKeepsZeroQuantity(t *testing.T) with 1 table case reproducing the reported input.

Go's test conventions make regression tests easy to place and easy to find later. The file is a _test.go in the same package, the function is a capitalized TestXxx taking *testing.T, and the failure is reported with t.Errorf including the got and want values so the next reader sees the gap immediately. Atlas copies the module's existing style rather than introducing a new one. The write tool shows the diff in the permission prompt before anything lands on disk, so the new test is reviewed before your module has it. Run gofmt on the file so the addition matches everything around it.

## How does the bash exit code prove a Go test is red?

Atlas runs the test with the bash tool, for example go test -run TestDiscountKeepsZeroQuantity ./internal/billing, and confirms it fails. The tool records the process exit code in its metadata alongside the output, so an exit code other than 0 from go test is unambiguous proof that the new test reproduces the bug.

Filtering with -run keeps the output to the one test under construction, which makes the got and want values easy to read while you refine the assertion. If go test exits zero at this stage, the test is not exercising the bug and Atlas revises it before touching any production Go code. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so the go test invocation stops for your approval unless you have allowed it. A run that ends non-zero is the green light to write the fix, which is the only time in this workflow that a failure is good news.

## How does Atlas apply the Go fix without breaking the wrong line?

Atlas applies the Go fix with the edit tool, whose replacer cascade requires an exact-enough oldString and refuses ambiguous multi-match replacements. In Go, where if err != nil { return err } can appear 20 times in a single file, refusing an ambiguous match is what keeps the patch on the intended line.

Ambiguity is not a theoretical risk in Go source. Error handling blocks, struct field assignments, and range loops repeat almost verbatim across a package, and a naive string replacement patches whichever one it found first. The edit tool demands enough surrounding context to identify exactly one site and refuses when it cannot. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so the change to internal/billing/discount.go is reviewed before it lands. Atlas snapshots file changes as git patches so edits can be diffed and rolled back if the fix proves wrong under the wider suite.

## How do you confirm a Go fix did not break anything else?

Atlas re-runs the exact same go test -run command and confirms the regression test now passes, then runs the wider suite with go test ./... to check for collateral damage. A fix inside a shared package in a Go module can break 3 other packages that import it, and only the wide run finds them.

Two runs, two purposes. The narrow run with -run proves the specific bug is fixed, using the identical command that was red minutes earlier, so nothing about the comparison is fuzzy. The wide run with go test ./... proves the fix did not trade one bug for another, which matters because Go's implicit interface satisfaction means a changed signature can quietly break a consumer that never named your type. Run gofmt on the touched files, then let Atlas stage the test and the fix together, since Atlas reads git branches, status, and diffs and can stage and create commits on your behalf.

## Steps

1. Run atlas in a Go module with a go.mod and let Atlas read your packages, interfaces, and go.sum dependencies.
2. Reproduce the bug once with the bash tool, capturing the exact failing command (for example go test ./internal/billing) and its full output including any panic stack.
3. Write the regression test with the write tool as a func TestXxx(t *testing.T) in a _test.go file beside the code, asserting on the observed wrong behavior with t.Errorf and got and want values.
4. Run the test with bash using go test -run TestXxx ./internal/billing and confirm it FAILS; the tool records the process exit code in its metadata alongside the output.
5. Apply the fix with the edit tool, whose replacer cascade requires an exact-enough oldString and refuses ambiguous multi-match replacements, which matters when if err != nil repeats across the file.
6. Review the unified diff Atlas surfaces before approving the write to the production Go file.
7. Re-run the same go test -run command and confirm the test now passes, then run go test ./... across the module to check for collateral damage.
8. Run gofmt on the touched files and have Atlas stage the test and the fix as one commit.

## FAQ

### how do I write a regression test in go for a bug I just fixed

Write the test before the fix, not after. Add a func TestXxx(t *testing.T) in a _test.go file asserting on the wrong behavior you actually observed, run go test -run TestXxx to confirm it fails, then apply the fix. Atlas enforces exactly that order using its bash, write, and edit tools.

### how do I run a single go test by name

Use go test -run TestName ./path/to/package, which filters to that one test and keeps the output small. Atlas runs it through the bash tool, which records the process exit code in its metadata alongside the output, so red and green are unambiguous.

### why does my go regression test pass before I write the fix

The test is not reaching the broken branch, so it guards nothing. Reproduce the bug with bash first and assert on the exact got and want values from that output. Atlas requires a non-zero exit code from go test before it will apply any fix with edit.

### how do I stop an AI agent from patching the wrong error handling block in go

Atlas's edit tool uses a replacer cascade that requires an exact-enough oldString and refuses ambiguous multi-match replacements, so a repeated if err != nil { return err } block will not be silently patched at random. Atlas also surfaces a unified diff for approval before writing.

### should I run go test ./... after fixing a bug

Yes. Re-run the narrow go test -run command first to prove the specific regression test is green, then go test ./... across the module. Go's implicit interface satisfaction means a changed signature can break a consumer that never named your type.

### can an AI coding agent run go test for me

Yes. Atlas runs go test through its bash tool, which is a real shell. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so the command stops for your approval unless you have allowed go commands in advance.

### how do I undo a go fix an AI agent made

Atlas snapshots file changes as git patches so edits can be diffed and rolled back, and reads git branches, status, and diffs so you can see exactly what changed before deciding. A fix that breaks go test ./... is a revert rather than a manual unwind.

### does atlas read my go.mod and go.sum

Yes. Run atlas in a module with a go.mod and let Atlas read your packages, interfaces, and go.sum dependencies. Atlas indexes code by AST declarations using tree-sitter, so Go funcs and methods are retrieved as whole declarations.

---

Canonical HTML: https://runatlas.sh/resources/stacks/add-a-regression-test-for-a-bug-fix-in-go
Source of truth: aeo_pages row `/resources/stacks/add-a-regression-test-for-a-bug-fix-in-go` (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.