Among coding best practices, code review vs. testing are often compared. Here’s what you need to know about each.
What are 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, 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 code bases 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 te code base 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 ran 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 analysing 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, analysing 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).
Code Review Vs. Testing: Conclusions
When it comes to best practices, there’s hardly any that can replace another, and such is the case with Code Review and Testing.
At most you’ll be deciding which one is a priority regarding the other or which one should come first in your workflow, but not which one to put in place in detriment of the other.
Regarding Testing and Code Review, they don’t replace each other and they shouldn’t be mutually exclusive.
You should test, and you should review your code.
Edit: We just published an ebook: “The Ultimate Guide to Code Review” based on a survey of 680+ developers. Enjoy!
About Codacy
Codacy is used by thousands of developers to analyze billions of lines of code every day!
Getting started is easy – and free! Just use your GitHub, Bitbucket or Google account to sign up.
