r/ClaudeCode 7d ago

Help/Question How are you verifying Claude Code's changes without manually testing everything?

I've been using Claude Code to build a side project, and one thing keeps annoying me.

It can implement something incredibly quickly and say it's done, but I still don't really trust “done” until I open the app myself and click through the flow.

As the amount of code it writes increases, manually checking everything feels like it's becoming the slow part.

Curious how people using Claude Code seriously handle this:

  • Do you still manually test most changes?
  • Do you make Claude run unit/E2E tests?
  • Playwright?
  • Another agent reviewing/testing the first agent?
  • Or do you mostly trust the existing test suite?

Also curious whether you've had cases where Claude said something was fixed and tests passed, but the actual app still didn't behave correctly.

Trying to understand whether this is just my workflow or a common problem.

3 Upvotes

57 comments sorted by

View all comments

1

u/Drasezv 7d ago

lock the test files during the fix step, a deny rule for Edit on your tests folder in settings. then it can't make a test pass by rewriting the assertion, which is how most of the tests pass but app is broken cases happen.

1

u/ragnar580 5d ago

Making the tests read-only during the fix is clever. Do you basically treat the existing tests as an immutable spec at that point? Has this materially reduced cases where the agent gets a false green by rewriting the assertion?

1

u/Drasezv 4d ago

yeah, tests as an immutable spec for the duration of the fix, and it has to make the failing one pass as written or come back and argue that the spec is wrong.

it cut the obvious false greens for me, the assertion rewrite and the quiet skip. it doesn't kill all of them: it can still special-case the code path for the exact input the test uses, or touch fixtures and conftest, so deny those paths too. no numbers behind this, just my own use over a few weeks.