Skip to main content
Best Practices with Mouse

Updating Tests with Precision

Insert, modify, and reorganize test suites without corrupting surrounding tests

The Problem

Test files are among the most edited files in any codebase, and they're uniquely vulnerable to the limitations of string replacement. Test files tend to be long, repetitive, and structurally sensitive; a misplaced bracket or a shifted assertion can silently break test isolation without producing a syntax error.

When your AI assistant needs to insert new tests, update existing assertions, or reorganize test suites, string replacement forces it to rewrite content around the insertion point. This creates risk precisely where reliability matters most.

What Goes Wrong Without Precision

Inserting new tests. A developer asks their assistant to add 10 new unit tests at a specific location in a long test file, between two existing test suites. The agent must find an anchor string near the insertion point, then issue a replacement that rewrites the anchor plus the new content. This risks deleting or corrupting the end of the preceding test suite or the beginning of the following one. The developer must review not just the 10 new tests but every surrounding line to verify nothing was inadvertently modified.

Updating assertions. A developer changes an API response shape and asks the agent to update the corresponding test expectations. The agent must find each assertion, echo the full line or block, and replace it. Across a test file with dozens of similar-looking assertions, ambiguous string matches are common; the agent may update the wrong assertion or skip one entirely.

Reorganizing suites. Moving a test block from one describe group to another requires deleting it from the original location and inserting it at the new one. With built-in tools, this means echoing the entire block for deletion (content-echo problem), then echoing it again for insertion. Two full copies of the same content, with double the opportunity for whitespace mismatches and formatting errors.

How Mouse Handles Test Edits

Inserting New Tests

Mouse's insert operation places content after a specific line number: no anchoring, no rewriting, no risk to surrounding content.

"Add 10 new unit tests for the validateInput function. Insert them after the existing describe('validateInput') block, before the describe('transformOutput') block."

The assistant identifies the insertion point by line number and stages the new tests. The surrounding test suites are never read, echoed, or touched. The developer reviews only the 10 new tests.

Updating Assertions

Character-level and line-level replacements let the assistant update specific assertions without rewriting surrounding test logic.

"Update all expect(result.status) assertions in the describe('API responses') block to check for 200 instead of 201. Only change the status value. Don't rewrite the expect statements."

The assistant targets the specific character positions where the status values appear and replaces them in place. If updating multiple assertions, batch editing stages all changes for review before committing.

Reorganizing Test Blocks

Moving content between locations combines deletion and insertion, both referencing the original file's line numbers.

"Move the describe('edge cases') block from the integration test file to the unit test file. Delete it cleanly from the source and insert it at the correct location in the target."

The assistant stages the deletion in the source file and the insertion in the target file as a single atomic batch. Both files are modified together, and the assistant reviews the staged result across both files before committing.

Prompting for Test Updates

Keep the instructions specific about what should and shouldn't change:

"Insert the new test suite after line 85. Don't modify the test suite above or below the insertion point."

"Update the expected values in these 6 assertions. Only change the values. Leave the test structure, variable names, and descriptions intact."

"Delete the deprecated test block cleanly. No leftover blank lines or broken brackets."

These patterns work with any test framework; the examples here use framework-agnostic patterns, but the same principles apply whether you're working with node:test, Mocha, pytest, or anything else.

Next Steps

You've now covered all six best practices: surgical precision, structure preservation, clean deletion, cross-file coordination, staged review, and test updates. To learn more about the technical details behind these capabilities, continue to Architecture Overview in the How Mouse Works section.