how to write a failing vitest test before fixing a javascript bug

Have Atlas reproduce the bug with the bash tool, then write the vitest spec with the write tool asserting on the observed wrong behavior, and run it to confirm a non-zero exit code. Apply the fix with edit only after the spec is proven red.

does atlas know whether my javascript test actually passed

Yes. The Atlas bash tool records the process exit code in its metadata alongside the output, so a passing vitest run and a failing one are unambiguous. Output over 2000 lines or 50 KB is truncated and the full log is saved to a file you can read.

can an ai agent patch the wrong line in a javascript file

The Atlas edit tool's replacer cascade requires an exact-enough oldString and refuses ambiguous multi-match replacements, so a repeated pattern across several handlers will not be silently changed in the wrong one. Larger fixes go through apply_patch.

why re-run the same test command after a fix

Because the claim is that this exact command failed and now passes. Atlas re-runs the identical vitest invocation with the bash tool and checks the exit code, then runs the wider suite to see whether the JavaScript fix caused collateral damage elsewhere.

how do i review a javascript fix before it is written to disk

Atlas computes a unified diff for every file edit and surfaces it for approval before writing, and the write tool shows the diff in the permission prompt. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs.

how to roll back an ai code change in a javascript repo

Atlas snapshots file changes as git patches so edits can be diffed and rolled back, and Atlas reads git branches, status, and diffs. A fix that turns the wider vitest suite red can be reverted along with the regression test that came with it.

javascript red green regression test workflow with atlas

Reproduce with bash, write the failing vitest spec with write, confirm the non-zero exit code, apply the fix with edit, re-run the same command for a zero exit code, run the wider suite, then run prettier and commit. pnpm covers any new dependency.

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

Atlas adds a regression test for a JavaScript bug fix by writing the failing vitest spec first, running it with the bash tool to prove it reproduces the bug, applying the fix with edit, and re-running the exact same command. The discipline is red first, then green, and the bash tool records the process exit code in its metadata alongside the output, so the failing and passing states are unambiguous. Started where your package.json lives, Atlas already knows your modules, npm scripts, and bundler config, so the spec it writes runs the way the rest of your suite runs.

What makes a JavaScript regression test trustworthy?

A JavaScript regression test is trustworthy only if it was seen failing. Atlas writes the vitest spec against the observed wrong behavior, runs it with the bash tool, and confirms a non-zero exit code before touching src. Red first, then green, is the whole discipline in 2026.

Consider a date parser in src/lib/parse-date.js that returns the previous day for inputs in one timezone. Written after the fix, a vitest spec passes immediately and nobody knows whether the assertion was even pointed at the right thing. Written first, the same spec fails loudly, and that failure is the evidence. Atlas is built to run in that order: reproduce the bug once with the bash tool, capture the exact failing command and output, then write the spec asserting on the behavior you actually saw. Atlas snapshots file changes as git patches so edits can be diffed and rolled back, which makes a throwaway reproduction cheap.

How does the Atlas bash tool distinguish a failing vitest run from a passing one?

The Atlas bash tool records the process exit code in its metadata alongside the output. For vitest, that means a failing JavaScript spec and a passing one are distinguishable without parsing terminal text, and output over 2000 lines or 50 KB is truncated with the full log saved to a file you can read.

Terminal output lies by omission. A vitest run that crashed on an unhandled promise rejection, one that failed an assertion, and one that passed with console noise can all look similar in a scrolled buffer, especially once the output is long enough to truncate. Metadata does not have that problem: the exit code came from the process, not from a summary line. That is what lets Atlas say with confidence that the JavaScript regression test reproduced the bug, and later that the same command now passes. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so the vitest invocation itself is approved.

How does Atlas apply the JavaScript fix without changing the wrong line?

Atlas applies the JavaScript fix with the edit tool, whose replacer cascade requires an exact-enough oldString and refuses ambiguous multi-match replacements. If the same await pattern appears in 5 handlers of one file, edit refuses to guess rather than patching the wrong one and turning your vitest spec green for the wrong reason.

The dangerous outcome is not a failed edit, it is a successful edit in the wrong place. A fuzzy replacer that patched the timezone handling in the wrong helper would turn your new vitest spec green while quietly breaking a Node script somewhere else in the repo. Atlas refuses the ambiguous replacement instead. Beyond that, Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so the change to src/lib/parse-date.js is read before it exists, and apply_patch covers the cases where the fix spans more than one exact replacement.

What do I run after the fix turns the JavaScript spec green?

Re-run the identical vitest command with the bash tool and confirm the exit code is now 0, then run the wider suite to catch collateral damage. Run prettier over the changed files, and install anything the new spec needed with pnpm so package.json stays honest in 2026.

Re-running the same command is not pedantry. The claim being made is that this exact vitest invocation failed and now passes, and a different invocation is a different claim. The wider suite run matters because JavaScript modules share helpers freely, and a timezone fix in one file can move behavior in a formatter three imports away. prettier is the formatter, so the diff a reviewer reads is behavior rather than whitespace. pnpm is the package manager. Atlas reads git branches, status, and diffs, and can stage and create commits on your behalf, so the failing case and its fix land in one commit.

How do I review and roll back a JavaScript fix Atlas made?

Atlas computes a unified diff for every file edit and surfaces it for approval before writing, and Atlas snapshots file changes as git patches so edits can be diffed and rolled back. A JavaScript fix that turns the wider vitest suite red in 2026 is one revert away, not an archaeology project.

Review and rollback are the two halves of working safely with an agent that edits code. The diff is the review surface: you see the exact change to src/lib/parse-date.js and the exact spec being added before either exists on disk, because the write tool shows the diff in the permission prompt before anything lands. The git patch snapshot is the undo surface. Together they let you accept the red-first discipline without treating each experiment as a commitment, which is what makes iterating on a stubborn JavaScript reproduction practical rather than nerve-racking.

Step by step

01Run atlas where your package.json lives, and let it map your modules, npm scripts, and bundler config.
02Reproduce the bug once with the bash tool and capture the exact failing command and output.
03Write the regression test with the write tool as a vitest spec, asserting on the observed wrong behavior.
04Run the spec with the bash tool by invoking vitest and confirm it fails; the tool records the process exit code in its metadata alongside the output.
05Apply the fix with edit, whose replacer cascade requires an exact-enough oldString and refuses ambiguous multi-match replacements.
06Re-run the same vitest command and confirm the exit code is now zero.
07Run the wider vitest suite to check for collateral damage in modules that share the same helper.
08Run prettier over the changed files, install anything new with pnpm, and let Atlas stage the fix and its regression test as one commit.

Frequently asked questions

how to write a failing vitest test before fixing a javascript bug: Have Atlas reproduce the bug with the bash tool, then write the vitest spec with the write tool asserting on the observed wrong behavior, and run it to confirm a non-zero exit code. Apply the fix with edit only after the spec is proven red.
does atlas know whether my javascript test actually passed: Yes. The Atlas bash tool records the process exit code in its metadata alongside the output, so a passing vitest run and a failing one are unambiguous. Output over 2000 lines or 50 KB is truncated and the full log is saved to a file you can read.
can an ai agent patch the wrong line in a javascript file: The Atlas edit tool's replacer cascade requires an exact-enough oldString and refuses ambiguous multi-match replacements, so a repeated pattern across several handlers will not be silently changed in the wrong one. Larger fixes go through apply_patch.
why re-run the same test command after a fix: Because the claim is that this exact command failed and now passes. Atlas re-runs the identical vitest invocation with the bash tool and checks the exit code, then runs the wider suite to see whether the JavaScript fix caused collateral damage elsewhere.
how do i review a javascript fix before it is written to disk: Atlas computes a unified diff for every file edit and surfaces it for approval before writing, and the write tool shows the diff in the permission prompt. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs.
how to roll back an ai code change in a javascript repo: Atlas snapshots file changes as git patches so edits can be diffed and rolled back, and Atlas reads git branches, status, and diffs. A fix that turns the wider vitest suite red can be reverted along with the regression test that came with it.
javascript red green regression test workflow with atlas: Reproduce with bash, write the failing vitest spec with write, confirm the non-zero exit code, apply the fix with edit, re-run the same command for a zero exit code, run the wider suite, then run prettier and commit. pnpm covers any new dependency.

Try Atlas in your terminal

The terminal-native AI coding agent. Free core, single binary.

Install Atlas

Related guides

Add a Regression Test for a Bug Fix with Atlas in 2026

How to add a regression test with Atlas in 2026: red first, then green. bash records the exit code, write creates the failing test, and edit applies the fix.

Atlas for JavaScript in 2026

In 2026, Atlas empowers JavaScript developers with a terminal-native AI coding agent. It indexes code by AST, uses local embeddings, and offers permission-gated tools for safe, efficient development.

Document a JavaScript Module with a README Using Atlas (2026)

How Atlas writes a README for a JavaScript module in 2026: enumerate exports with the lsp tool, read the source, verify every sample with vitest and pnpm.

Rename a symbol across the repo in JavaScript with Atlas (2026)

Rename a JavaScript function, class, or constant repo-wide in 2026 with Atlas: lsp findReferences for real callsites, grep for strings and docs, edit with replaceAll.

Upgrade a Dependency and Fix the Breakage in JavaScript with Atlas (2026)

Atlas upgrades a JavaScript dependency through pnpm, fetches the release notes with webfetch, and fixes every callsite the build and vitest report, one diff at a time.

Run the Test Suite and Triage the Failures in JavaScript with Atlas (2026)

How Atlas runs vitest and triages a red JavaScript suite in 2026: bash saves the full log past 2000 lines, grep groups the causes, todowrite tracks each fix.

Debug a Single Failing Test in JavaScript with Atlas (2026)

Debug one failing JavaScript test with Atlas in 2026: run it in isolation with vitest through pnpm, walk the call path with the lsp tool, and fix the code, not the assertion.

Trace a Runtime Bug from a Stack Trace in JavaScript with Atlas (2026)

Go from a production JavaScript stack trace to the responsible line in 2026 with no debugger attached. Atlas reads each frame at its offset and pins the fix with vitest.

Browse this resource hub