Write tests before you review a pull request

Code reviews have a few basic rules: an author submits a change, a reviewer reads it, offers feedback, and approves it when issues are resolved. Sounds simple, but we know it goes way, way deeper than that.

It's really more of an art form than a process. Every interaction between author and reviewer carries layers of nuance that add up and have major impact on the final shape of code that we ship. This makes it always worthwhile to invest in making it even 1% better.

I won't be discussing all the different aspects in this post – I can recommend other reads for that^{1 2}. Instead, I'd like to talk about just one underrated idea:

Instead of jumping into the diff and reading the change... actively avoid learning any details by the author's description on how they implemented the change and instead begin by writing your own test cases documenting your understanding of the requirements. Not real valid code, but pseudocode; a simple list of bullet points.

I strongly believe this will level you up as a reviewer if you weren't already doing this.

Let's go back to first principles: what's the primary goal of code reviews?

• Is it to ensure readability? No.
• Good design? No.
• Shared responsibility and understanding? Nope.

The main reason code reviews happen is the same reason we wrote the code in the first place: to solve business problems. If the proposed change doesn't address the product problems we set out to solve, then it's not good code no matter how well-designed and readable it is.

That's the principle behind writing our own test cases before reading the implementation: we allow ourselves to think critically without bias about what the implementation should look like and what it should cover.

Skip the code, skip the pull request description, look for the ticket and understand the core requirements. Write down the test cases you expect for the implementation to be complete. Only once you've done this, you can read the code.

The moment we peek at the author's implementation we become biased, making it more difficult to think of alternative approaches and provide an insightful review. Sometimes, you'll find that the author has done an excellent job and thought of edge cases that didn't occur to you. Other times – and hopefully not often – you'll find that your idea of how this change should be implemented has clear and desirable advantages over the proposed version.

Of course, there's also value in iteration. Just because a change is not perfect does not mean it shouldn't land as is. That's up to you and your team to decide. But it goes to show how reviewing code is rarely clear-cut, and that's what makes it an art!