4.3Giving Constructive Feedback

The goal of code review is to improve the code, not to demonstrate your superiority. Frame feedback as questions or suggestions, not commands.

Bad Feedback

"This is wrong."
"Why would you do it this way?"
"This will never work."

Better Feedback

"Have you considered using a data-testid selector here? In my experience,
CSS class selectors tend to break when the design team updates styles."

"I think this assertion might be flaky because it depends on animation
timing. What if we wait for the element to be stable first?"

"Nice approach! One thought: could we extract this setup into a fixture
so other tests can reuse it? I see a similar pattern in checkout.spec.ts."

Feedback Calibration

Severity	Action	Example
Blocking	Request changes	Test has no assertions; hardcoded credentials
Suggestion	Comment but approve	"Consider extracting this into a helper"
Nit	Prefix with "nit:"	"nit: rename btn to submitButton for clarity"
Question	Ask for clarification	"Is the 5-second timeout intentional? Seems long for a unit test"
Praise	Comment positively	"Nice edge case coverage on the empty cart scenario"

Approve with minor comments rather than blocking on style preferences. Reserve "request changes" for issues that would cause real problems (flakiness, missing assertions, security concerns).