Same plan, same experience. Trying to get it to develop and execute tests and it frequently modifies the test to succeed even if the libraries it calls fail, and then explains that it’s doing so because the test itself works but the underlying app has errors.
Anthropic, if you're listening, please allow zoned access enforcement within files. I want to be able to say "this section of the file is for testing", delineated by comments, and forbid Claude from editing it without permission.
My fear when using Claude is that it will change a test and I won't notice.
Splitting tests into different files works but it's often not feasible, e.g. if I want to write unit tests for a symbol that is not exported.
I've had some middling success with this by utilizing CLAUDE.md and language features. Two approaches in C#: 1) use partial classes and create a 'rule' in CLAUDE.md to never touch named files, e.g. User.cs (edits allowed) User.Protected.cs (not allowed by convention) and 2) a no-AI-allowed attribute, e.g. [DontModifyThisClassOrAttributeOrMethodOrWhatever] and instructions to never modify said target. Can be much more granular and Claude Code seems to respect it.
Don't put the onus (Opus!) on me! Just a dad approach to helping. If there's enough time to writ prose about the problem you could at least rtfm first!
> allow zoned access enforcement within files. I want to be able to say "this section of the file is for testing", delineated by comments, and forbid Claude from editing it without permission.
I think you missed a critical step: 1.5: know that "allowed tools" is the correct incantation required to summon the relevant documentation; which, at least to me, is not obvious at all in the context of the OP.
Yes, I know. That’s what the test was for.