Case Study: Google’s Team Approach to Coverage

We spend our days (and nights and really anytime we have) developing quality and beautiful .NET applications. We pour over our code, testing and coverage to make sure it is good. Some of us do that on our own while others are part of a larger network of teams with managers, developers and quality assurance members all along the way.

We all want to know that our code is good. We write tests to prove that and use coverage tools to show that we have strong tests. Rolling out a coverage process can feel pretty daunting whether you are in the same building or across the globe.

The team at Google recently gave us all a peek behind their curtain about implementing code coverage team-wide and its effects across the organization. (You can read the whole post here). We spliced it down into the Cliff’s Notes version with some key takeaways.

Their team’s mission was to collect coverage related data and then develop and implement the code coverage practices company wide. To make it easy, they designed an opt-in system where engineers could enable two different types of coverage measurements for their projects: daily and per-commit. With daily coverage, Google ran all tests for their project, where as with per-commit coverage they ran only the tests affected by the commit. The two measurements are independent and many projects opted into both.

The feedback from Google engineers was overwhelmingly positive. The most loved feature they noted was surfacing the coverage information during code review time. This early surfacing of coverage had a statistically significant impact: their initial analysis suggests that it increased coverage by 10% (averaged across all commits).

Their process is ever-changing and growing. We will keep you posted on their activity along the way.