Gustavo Silva for Codacy

Posted on Apr 7, 2021

Code Review vs. Testing

#codereview #codequality #testing #productivity

Among coding best practices, code review vs. testing are often compared. Here’s what you need to know about each.

What is Code Reviewing and Testing?

Code Review

Code refers to the act of inspecting code; this can be done in the search for bugs, code style policy violations, security vulnerabilities, the extreme complexity of code, etc. The goal is towards code quality but also making sure the code does what it is supposed to do.

Testing

Testing is actually a vague description, as it might refer to several types of testing; for the purpose of this article, we’ll consider Unit Tests: tests that are implemented and can be run automatically with every build or even every commit to making sure former bugs don’t show up again (other types of testing include Regression testing, Integration testing, and Smoke Testing, to name a few, but we’ll leave these for a future post).

Does Code Review replace Testing?

Not at all.

I have seen this quite too often: strong Code Review processes in place with no deployments until everything is inspected by a senior member of the team, only to reintroduce bugs that were thought to be in the past.

As codebases grow it becomes harder and harder to keep everything in one’s mind, and sometimes it’s easy to overlook the appropriate way to use a method, the appropriate parameters to use, or the side effect of an action in very a specific circumstance.

With more than one reviewer present (unless it’s mandatory that code is reviewed by all of them) each reviewer begins accumulating blind areas of the codebase that are only known to certain members of the team.

Couple with the fact that the larger the platform the harder it is to manually test everything after each deployment, the absence of Unit Testing renders every update into a minefield packet with bombs that will only go off whenever a user named Murphy comes along.

Does Testing replace Code Review?

The following actually happened: big company, big client, big solution. There was a dedicated testing team that implemented every possible scenario they could think of, and they ran the tests every single day.

The client was a major political party about to use the platform for communication purposes on elections day.

What could possibly go wrong, right?

Sadly, when launched, the system simply didn’t work, and it being a Sunday meant that the team wasn’t readily available.

What caused the problem?

The fact that it was Sunday.

And that the tests had only run from Monday to Friday.

As it turns out, the platform had a bug that rendered it inoperable during Sundays (something to do with 0-indexed arrays).

In retrospect, Code Review could have indeed saved the day, as analyzing the code with a thorough attitude could have caught this particular flaw.

While testing is important, in this case, it didn’t really account for every possible scenario*.

That’s where a human comes in, analyzing code with a critical mindset and thinking of possibilities that may have been neglected when the tests were written.

Also, Code Review is not just about catching bugs that could’ve been caught through testing. Code Review also targets readability/maintainability, code complexity, performance, unused or duplicated code, etc.

* — For those wondering whether it would be possible to test every possible scenario: the answer is no.

While you could have tests running on weekends as well you’d still be missing all the other possibilities: nights, different machines, bugs that only manifest if the code hasn’t run for the past 3 hours, or even flaws that only become meaningful when a specific amount of users is connected to the platform (not necessarily a huge amount of users, which would be covered by Stress Testing, but rather a specific amount of users, such as 11).