Test Automation Code Review Process

Automation Code Review Process

Summary: In world of globalization, it is most common practice to have people with different background & style working on the same application or code module. With this kind of setup, it is difficult to achieve code uniformity. So it’s always a good practice to have a process to standardize coding styles across teams. That’s where having a strong test automation review process helps. In the world of agile development where developing an application is just month’s business, one can argue about not wasting time for code reviews. But like the development life cycle has evolved over the period of time, the test automation code review process has also evolved. This article is all about the artifacts of code review.

Code review is systematic examination (often known as peer review) of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills.

As described in the summary of this article, the code review process has evolved to cope up with faster development life cycle like agile development. With the amount of tools, plug-ins, processes, etc. available for code review, it has become super-fast these days. Code review is no more a formal process where teams sit together and tear the code apart to find out bugs. This conventional process is effective but time consuming.

Types of Code reviews

The code reviews are categorized into two types, one is formal code review and another is light weight code review.

Formal code review involves a careful and detailed process with multiple participants and multiple phases. Formal code reviews are the traditional method of review, in which software developers attend a series of meetings and review code line by line, usually using printed copies of the material. Formal inspections are extremely thorough and have been proven effective at finding defects in the code under review.

Lightweight code review typically requires less overhead than formal code inspections, it is equally effective. Lightweight reviews are often conducted as part of the normal development process:

• Over-the-shoulder – One developer looks over the author’s shoulder as the latter walks through the code.

• Email pass-around – Source code management system emails code to reviewers automatically after check-in is made.

• Pair Programming – Two authors develop code together at the same workstation; such is common in Extreme Programming.

• Tool-assisted code review – Authors and reviewers use specialized tools designed for peer code review.

Some of these may also be labeled a “Walkthrough” (informal) or “Critique” (fast and informal).

Above listed are the simplest and effective techniques one can implement for reviewing source code. Most of the project these days use source control tools to store and manage code. Every source control system has some or other way to package change lists (delta between code on server and code on client). E.g. TFS has shelve sets, Tortoise SVN has patches, Source depot has DPKs etc. The technology used for packaging the changes is very useful in setting up the code review process. Every packaged change list is can be opened up with code diffing tool which shows code changes line by line and that can be very useful in identifying changes in code, hence code review. The simplest code review process that can be implemented by using these packages and the diffing tool.

Scenario: Every project these days has some or other source control system and people do their daily check-ins in the source control. But when it comes to implementing test automation code review process, everyone runs away saying, it’s complicated to setup, we don’t know which tool to use, we cannot share code and blah blah blah. These are the most common reasons we hear when we want to do code review.

Example below shows simplest and easiest way to setup a code review process in your project. I will be referring Tortoise SVN as source control.

Problem:

• Tom has just finished doing changes to the Email module code on the local copy of source tree. Since there is no code review process setup Tom checked in the code in source tree which resulted in breaking of the build due to a missing file. Tom realized this after seeing an email from build engineer.

• Tom approached his senior Larry and asked about how he can reduce the risk of build breaks using simple process.

Solution:

• Larry, after thinking it through, has come up with simplest and easiest technique for doing code review using the existing infrastructure and tools they have been using since long.

• The next day in office, Tom comes and finishes coding. He then builds the code at his end and creates a patch of the changes he has done to the code. He then sends his patch to Larry for code review.

• Larry opens up the patch in one of the diffing tool provided by source control Tortoise SVN. The changes done by Tom looked like the one’s shown in the images below. 

• Larry realizes that Tom has unintentionally deleted a line from one of the file (as highlighted in red above) which caused a build error on Larry’s machine.

• Larry then emails back to Tom saying the file was unintentionally removed and caused a build failure.

• Tom then reverts his changes to the file and resends the updated patch for code review to Larry.

• Larry checks out the code and replies back saying the changes look good.

• Tom then checks in his changes to source tree.

In this scenario, because of the code review process, Tom and Larry avoided the potential build failure which could have caused unnecessary escalations from client. Above was very simple, lightweight and effective process by which such issues can be avoided.

In the world of agile and cloud, code review has also become very simple and easy to setup and follow. Here are some tools which can be used for implementing code review process and doing code analysis.

Resharper – Code inspection tool which can automatically refactor your code.

Style Cop – Another code inspection tool for having a check on coding style.

Windiff, Odd, SVN diff – Diffing tool which can tell you the difference between two files.

Code Flow – Code review tool which can easily be integrated to TFS.

JIRA Crucible – Online code review tool, embedded in JIRA and capable of code diff, maintaining comments, etc. Tools like JIRA provided online way of doing code reviews where one can easily see the difference online using JIRA account.

With all these tools by your side, don’t be hesitant to start code review process in your project. Do code reviews, it’s another way of learning how to code.