Start with a failure.
A test earns its place by catching the behavior you need to change.
A green test added after a patch can feel reassuring without proving much. Begin with the requirement and a case that exposes the current failure. Use the project's existing test tools so the new evidence belongs to the normal workflow.
Check the check.
Run the focused case against the original implementation. Read the failure message: a missing dependency or malformed fixture does not demonstrate the bug. Ask the assistant to explain why the expected result follows from the requirement.
- Blank name
- Rejected; previous name remains.
- Valid new name
- Saved through the existing flow.
- Failed save
- No false success message.
Change the minimum behavior.
Implement the requirement using the surrounding conventions. Keep the acceptance check stable unless you discover that it misstates the requirement. If you change the expectation, document the reason and establish the failure again before calling the result verified.
Widen with a reason.
Rerun the focused check, then the relevant existing checks around the touched behavior. Broaden further when the patch affects a shared interface or a new failure raises a real concern. Repeating the same passing command without new evidence adds little.
Record: check name, actual result, and relevant output.
Also record: any check that could not run, and why.
Do not translate "not run" into "passed".Before moving on