Do We Need to Test UI Changes During Code Review?

Pandiyan MuruganLeave a comment

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.

🚀 Fixing Time Limit Exceeded in “Longest Consecutive Sequence” (LeetCode 128)

Pandiyan MuruganLeave a comment

Introduction

LeetCode’s Longest Consecutive Sequence problem challenges us to find the longest sequence of consecutive numbers in an unsorted array in O(n) time. My initial approach seemed correct but ran into Time Limit Exceeded (TLE) issues. After optimizing the code, I discovered that removing elements from the HashSet significantly improved performance. Let’s explore why!

My Initial (TLE) Solution

This solution checks each number and expands the sequence while map.Contains(num + length) remains true.

public class Solution {
    public int LongestConsecutive(int[] nums) {
        HashSet<int> map = new HashSet<int>(nums);
        int result = 0;

        foreach (int num in nums) {
            if (!map.Contains(num - 1)) { // Start of sequence
                int length = 0;
                while (map.Contains(num + length)) { 
                    length++;
                }
                result = Math.Max(result, length);
            }
        }
        return result;
    }
}

Why Does This Cause TLE?

🔴 Repeated Lookups: The while loop checks the same numbers multiple times.
🔴 Inefficient for Large Inputs: If the array is large, map.Contains(num + length) is called unnecessarily.

Optimized Solution (With set.Remove(currentNum))

Instead of checking the same numbers again, we remove elements from the set once we process them.

public class Solution {
    public int LongestConsecutive(int[] nums) {
        if (nums.Length == 0) return 0; // Handle empty array

        HashSet<int> set = new HashSet<int>(nums);
        int maxLength = 0;

        foreach (int num in nums) {
            if (!set.Contains(num - 1)) { // Start of sequence
                int currentNum = num;
                int length = 1;

                while (set.Contains(currentNum + 1)) {
                    currentNum++;
                    length++;
                    set.Remove(currentNum); // Remove to avoid rechecking
                }

                maxLength = Math.Max(maxLength, length);
            }
        }
        return maxLength;
    }
}

Why Does set.Remove(currentNum) Improve Performance?

✅ Each number is processed only once
✅ Avoids redundant Contains() lookups
✅ Reduces unnecessary iterations, ensuring O(n) complexity

By removing currentNum from set, we make sure that we never check the same number twice, significantly improving efficiency.

Time Complexity Analysis

  • Initial approach: Worst-case O(n²) due to redundant lookups. ❌
  • Optimized approach: O(n) since each number is visited only once. ✅

Final Thoughts

This simple fix—removing elements as they are processed—helps avoid unnecessary checks and reduces execution time drastically. If you’re facing TLE on LeetCode 128, adding set.Remove(currentNum) is the key! 🚀

What do you think? Have you faced similar performance issues? Let me know in the comments! 😊

Disclaimer: Code is fully written by me in this blog, but the text explaining the problem is generated with help of AI.