Tell Claude to Run Tests After Every Change and Fix What Breaks
The most common way Claude introduces bugs is by making several changes before testing. Each edit is correct in isolation, but together they break something. The fix is simple: test after every change.
"Refactor the payment module to use the new pricing engine. Run the tests after each change and fix any failures before moving on."
Claude shifts into an incremental loop: make one change, run the tests, fix anything that broke, confirm green, then proceed to the next change. If a test fails, Claude fixes it immediately — before the context of what it just changed is stale.
This is especially valuable for:
# Multi-file refactors
"Extract the email logic into a notification service. Move one method at a time,
run tests after each move, and fix any broken call sites before continuing."
# Dependency updates
"Update the authentication library. After each config change, run the auth tests
to make sure nothing breaks."
# Database changes
"Add soft deletes to the Order model. Run tests after the migration,
after updating the model, and after updating the queries."
You can specify which tests to run for faster feedback:
"Refactor UserService — after each change, run just the user tests with
php artisan test --filter=User. Run the full suite at the end."
The pattern works at any granularity:
- Per-file — "run tests after editing each file"
- Per-feature — "run tests after completing each feature change"
- Per-method — "run tests after moving each method" (for careful refactors)
Compare the results: without this pattern, Claude makes 10 changes and you get a wall of test failures with interleaved causes. With it, each failure is immediately traceable to the one change that caused it.
Green tests after every edit isn't slower — it's faster, because you never have to debug five changes at once to find the one that broke something.
via Claude Code
Log in to leave a comment.
Set up Claude Code as an automated reviewer in your CI pipeline — on every pull request, it reads the diff, checks for bugs, security issues, missing tests, and convention violations, then posts its findings as a PR comment. Your human reviewers get a head start because the obvious issues are already flagged before they look.
Before deploying, tell Claude to read your project — migrations, environment variables, queue workers, scheduled tasks, caching, third-party integrations — and generate a deployment checklist that's specific to your app. Not a generic "did you run migrations?" list, but one that knows YOUR infrastructure and catches the things YOUR deploy can break.
Instead of writing a README from memory or copying a template, tell Claude to read your project and generate one that's actually accurate — real setup instructions from your config, real architecture from your directory structure, real API examples from your routes, and real prerequisites from your dependency files.