Do We Need to Test UI Changes During Code Review?

Pandiyan Murugan

Code reviews are a crucial part of the development process. They help catch bugs early. They maintain code quality and guarantee consistency. But when it comes to UI changes, one question that comes up every time –

“Should I test every UI change during code review?”

Let’s break it down.

The Real Deal

When reviewing code, your job isn’t to become a full-time QA. You’re not expected to click through every screen or test every browser. But that doesn’t mean you just review the code and approve without even running it.

Here’s a simple rule I follow:

Do a smoke test. Leave deep testing to the person who wrote the code.

Responsibilities – Who Does What?

Code Author (the one raising the PR):

  • Clear information of what has been changed.
  • Links to relevant to related requirements document if any.
  • Tests all use cases — positive, negative, edge cases.
  • Ensures responsiveness and accessibility.
  • Runs the app in different screen sizes (desktop, mobile, etc.).
  • Adds before/after screenshots or screen recording in the PR.
  • Mentions what was tested and how.

Code Reviewer (the one reviews the PR):

  • Pull the branch and run a quick smoke test.
    • Does the UI render?
    • Does it break anything obvious?
    • Are core interactions working? (clicks, inputs, nav)
  • Review the code:
    • Is the styling clean?
    • Any hardcoded values?
    • Are components reusable and scoped?
    • Does it break any layout in high level?

You’re the second line of defense, not the QA team.

When to Dig Deeper?

You don’t always need to click every flow, but in these cases, it’s worth going beyond a smoke test:

  • It’s a high-impact UI change.
  • There’s a risky refactor.
  • The code seems too simple for the change it claims to solve.
  • You’re curious or feel something’s off.

TL;DR

  • Do a smoke test during code review.
  • Let the code author do full testing.
  • Make sure they show what’s changed with screenshots or a demo.
  • Your goal: catch obvious issues, review clean code, ensure UI logic is solid.

Let your review be lightweight, focused, and valuable. Not every change needs a deep dive — just enough to ensure you’re not shipping broken UI.

Leave a comment