Tuesday, 20 December 2016

Automating code reviews (in the context of iOS development)

TL;DR - Run tests, analyse code coverage and enforce consistent code style automatically in pull requests so you can focus on actually reviewing the code
When it comes to reviewing code in pull requests, I find that it's important to focus on what the code is doing. Over time I found that automating certain processes related to code reviews has helped me do just that. This post is about explaining the three areas I automate in pull requests, how these things can be automated and why it's valuable to do so.

Automate things to skip some chores during code reviews, image by Nikolay Necheuhin

A few caveats

The tools mentioned all work if your repository is in Github and they are free if the repository is public. I can't say for certain they'll work with other repository hosting services but the concepts are still very much valid.
Note that this is not a step by step guide on how to integrate these tools into your codebase, most things are easy enough that by either looking into a project or doing a quick google search you can figure out how to set them up.

1. Running unit tests

The title is pretty self explanatory here. The idea is that on every pull request the unit tests are run so that any broken tests are flagged. This also has the added benefit of checking that the new code does not actually break the build.
The easiest way to run the unit tests on pull requests is using a cloud based continuous integration provider to avoid having to setup any servers. I've always used Travis CI for open source and I cannot recommend it enough. Alternatively, there are a lot of providers to choose from. Most of these tools will run both the unit tests on the code you push as well as the result of the merged code.
The key reason why this is very valuable is to ensure that broken builds are not merged into your main branch. If you have a reasonably good test suite it also mitigates against introducing bugs when adding new code. Finally, running tests on another system gives more confidence that the setup is independent on the computer it's running on. For example, if the Xcode scheme is not shared, you would be able to build locally but anybody cloning the repository will not be able to run a build.

2. Checking code coverage of new changes

Code coverage is the concept of keeping track of what lines are executed and which are not by your unit tests. Technically, you could write a test that executes every line of code in your project meaning the percentage coverage is not very meaningful on its own. A low percentage will flag a lack of unit tests but a large percentage is definitely NOT a guarantee of having a good test suite. 
The percentage code coverage can be global for the project or just for the diff in a pull request. Since Xcode 7 it's quite easy to generate coverage reports, it's only a tick in the scheme. The produced reports are not very useful on their own, it's best to post them to a code coverage service for analysis. Historically, I've always used Codecov but I know people that use Coveralls. Both have the same key features and integrate easily with Github, so I'd say choose whichever one you feel most comfortable with. I'm sure there are other tools that accomplish the same if you find neither to be suitable.
These tools comment on the pull request with the global and diff code coverage percentage as well as a detailed report of what lines are hit and which ones are not. I find this very valuable in flagging code paths that I forgot to test. Therefore, before merging a pull request it's possible to make an educated decision whether there is any value in testing any code that is not currently covered.

3. Enforcing code style

Most developers have their own styles and arguably there are no right or wrong styles. Enforcing is probably a strong word but generally speaking it's better to have a consistent style throughout the code you work on.
To do this there are quite a few options. I have tried Hound and Codacy, they work with different linting tools. Linting can mean quite a lot, in this case I'm referring to the process of finding code that doesn't correspond to a predefined style guideline. Personally I prefer Hound because it uses SwiftLint behind the scenes meaning that checking for code style can be done locally and any non-default rules can be defined in the swiftlint.yml file.
The main reason to enforce a style guide is so that new developers can be onboarded faster as they know what to expect. Hence, it's easier to focus on what the code is doing instead of how it looks since the code's style will be the same throughout.


To conclude, it's worth reiterating that these tools prevent you from wasting time looking for and commenting on boring issues allowing you to focus on what the code is actually doing. Setting up these three kind of integrations is very easy. Realistically for somebody with no experience it should not take more than a day.
For open source projects all these tools are free, so there's little reason not to configure them. If you do work on a private repository it's a good idea to invest in them as they will save you plenty of time in the long run.
This pull request shows an example in the status check of some of these tools in action. Travis CI has run the unit tests (both on the commit and the resulting merge), Codecov has analysed the code coverage, and Codacy and Hound have looked for any style issues.


  1. It’s therefore not surprising that organizations undertake several different types of review on there most important projects. From my perspective, there are five distinct types of review. Each with its own focus and outcome. Re-KaChing Bonus

  2. Wow, Excellent post. This article is really very interesting and effective
    IBM BPM Online Training in Chennai
    IBM BPM Online Training

  3. Decent Blog, When I was perused this blog I learnt new things and its genuinely have well stuff identified with creating innovation, Thank you for sharing this blog.
    Education | Article Submission sites | Technology

  4. Wonderful Content!!! Which is very simple and useful. It helped me a lot in sharing a knowledge

    iOS Course in Chennai

    iOS Training Chennai

  5. TreasureBox is operated by a group of young, passionate, and ambitious people that are working diligently towards the same goal - make your every dollar count, as we believe you deserve something better.
    Check out the best
    entertainment unit
    furniture nz

  6. This is an awesome post.Really very informative and creative contents. These concept is a good way to enhance the knowledge.I like it and help me to article very well.Thank you for this brief explanation and very nice information.Well, got a good knowledge.

  7. Your blog provided us with valuable information to work with. Each & every tips of your post are awesome.
    Rochester web design

  8. Looking for a pipe cutting machine in your area ? Then we are the best for you, who suit your expectations. We have huge experience in this field. We are 100% dedicated to finding you a high quality pipe cutting machine.
    If you want to know more, Please check out Cheers Electronic Technical Co.LTD: https://www.terminal-crimping.com/Pipe-Tube-Cutting-Tools.html


  9. The article provides good information and here i want to share some information about ibm bpm training and microsoft exchange tutorial