Test Coverage and Testing Culture at Google and Facebook
The article examines why test coverage matters, how Google and Facebook approach automated testing, the cultural emphasis on code ownership, and the practical limits of achieving 100% coverage in large-scale software projects.
If a bug affects only 0.01% of users of a small app, it may not be worth the effort, but the same percentage at Google or Facebook translates to thousands of complaints and potential media scandals.
Test Coverage
The illusion of code‑coverage metrics is that once you start combining code blocks and testing every possible path, even medium‑size projects quickly generate an almost infinite number of tests.
Therefore, the complexity of code in large applications leads to two conclusions: automated testing is necessary, and achieving 100% code coverage for a large app is unrealistic.
Google's Test Coverage
Without very high quality‑assurance standards, Google would not be as large as it is today. Fortunately, Google has published many blog posts about their testing and QA practices, giving us insight into their methods.
Images above show Google’s office and data from articles measuring Google’s code coverage. Marko Ivanković from Google’s z_rich team explains the polarized attitudes toward coverage metrics.
“Some people consider coverage a very useful metric and think a certain percentage should be enforced for all code. Others see it as a tool to identify areas needing more testing but do not trust that covered code is well‑tested. Some even argue that measuring coverage is actively harmful because it gives a false sense of security.”
To answer the importance of coverage, Marko studied two types of tests used at Google: daily builds and pre‑submit builds. Daily builds test work‑in‑progress code to alert engineers of bugs early, while pre‑submit builds focus on ensuring smooth submissions.
Google’s internal tool for marking whether code is covered is shown in the screenshot below:
Using this simple tool, after 100,000 commits Google increased overall code coverage by 10% across all projects.
The quality‑control part of this process is purely automated testing.
Facebook's Code Coverage
Facebook uses coverage tools to inform their automated test results. According to a former Facebook engineer, coverage remains high and varies by language:
PHPUnit is used for PHP unit testing and is a core part of Facebook’s architecture; tests can be triggered by developers, dedicated testers, or the software itself.
For testing user‑visible content, Facebook engineers use Watir, combining manual and semi‑automated testing.
Failed tests automatically notify developers and are logged in a database that developers can view.
With millions of lines of code, a strong testing culture is essential; otherwise, serious problems would arise.
Evan Priestly, a former Facebook engineer, notes that the company has no dedicated QA role—engineers are responsible for testing their own code because social media is not a safety‑critical product.
“By reducing investment in quality, Facebook can focus on making the company a fun place to work, attracting talent. If Facebook were overly focused on quality, it might not be as enjoyable. Social networks aren’t as critical as banks or rockets; this gives Facebook more flexibility.”
Testing Culture
Traditionally, developers write code and QA tests it. Google and Facebook, however, embed testing into the development process, emphasizing personal responsibility rather than a separate testing department.
Both companies treat testing as a cultural element; for example, Google’s job description for a game‑related API developer explicitly requires testing new features.
When hiring, Google looks for engineers who are not afraid to test, and Facebook expects release engineers to manage source control, automated builds, regression testing, and deployment tools.
How Google Tests Software
InfoQ reported in 2011 that Google’s testing team is small compared to developers, yet effective because each engineer owns testing for their own code.
Google built a testing culture rather than a separate department. Managing a codebase of 2 billion lines, they achieved massive success by embedding testing into development.
“Quality is a development problem, not a testing problem. We embed testing practices into development activities, creating a process where incremental changes can be rolled back individually. This prevents many customer issues and reduces the need for dedicated testers to catch recall‑type defects.”
Benefits include equal status for developers and testers, many‑to‑one testing, and allowing developers to focus on coding without excessive testing overhead.
Google uses its own tools such as the Google Test Case Manager and extensive automated testing.
How Facebook Tests Software
Facebook emphasizes code ownership, ensuring each engineer is fully responsible for the quality of their work.
Every line of code is reviewed by a different engineer, fostering motivation for high quality, fresh ideas, and knowledge sharing across the company.
Facebook leverages a large pool of beta testers (dark launches) to deploy new builds to a small user segment, catching defects before they affect the majority.
Engineers can quickly release new features and iterate.
Defects are fixed before 99.999% of users notice.
No dedicated testing staff is needed; a strong engineering culture ensures quality.
Tools used include PHPUnit, Watir, Boost, JUnit, and internally developed HipHop.
For more information, a “Continuous Delivery 2.0” seminar was announced, and the author’s new book is available for purchase.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Continuous Delivery 2.0
Tech and case studies on organizational management, team management, and engineering efficiency
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
