TDD gives Claude a clear order
AI-assisted test generation without control can produce weak assertions, excessive mocks, or a test that passes before the fix. TDD limits this risk through a sequence: expected behavior, a red test, the smallest fix, a green test, and only then small cleanup.
- Describe observable behavior.
- Write a test that fails on the current code.
- Make sure the failure is caused by missing behavior, not by a fixture or import.
- Make the smallest change to production code.
- Run the test and verify the green result.
- If needed, perform a small refactor without changing behavior.
A red test must be honest
A reliable test checks a result seen by a user or another system: an error field, a value, a blocked action, or an HTTP response. A test that only checks that “something was returned” can stay green while a defect remains.
Before making changes, confirm that the test has no fixture, mock, or import problems and really distinguishes the old implementation from the expected behavior.
Read the specification and validator.
Add only the test for the required behavior.
Do not change production code.
Explain why the test currently fails.The green stage and refactor boundaries
- Ask Claude to make a minimal fix within one risk boundary.
- Do not allow moving files or adding helpers or dependencies without a decision.
- After green, small cleanup of names or local duplication is acceptable.
- Move a large cleanup into a separate task.
- A green status does not cancel the diff review.
How to detect a weak AI-generated test
| Signal | Why it is a problem |
|---|---|
| The test passes before the fix | It does not prove that the original defect exists |
| Only a mock call is checked | A user or system result has not been proven |
| The object under test is mocked | The substitute is tested instead of real behavior |
| A large snapshot | The important contract is hard to see in the noise |
| An unclear name | It is unclear which risk is protected |
A safe prompt for test review
CLAUDE.md can preserve recurring rules: write a regression test first, do not touch production code before it, do not perform a large cleanup after green, and report the checks that actually ran.
Review only the test.
Determine whether it describes user behavior,
whether it could pass while a defect remains,
and whether it depends too heavily on mocks.
Do not change files.Canonical lesson source · JavaRush
Open JavaRush material