In this scenario, there are two tests and three changes that affect these tests. Here is an example where our system can provide faster and more precise feedback than a traditional continuous build. The system is built on top of Google’s cloud computing infrastructure enabling many builds to be executed concurrently, allowing the system to run affected tests as soon as a change is submitted. To solve this problem, we built a continuous integration system that uses dependency analysis to determine all the tests a change transitively affects and then runs only those tests for every change. To find the exact change that broke a test, we could run every test at every change, but that would be very expensive. A continuous integration system should help by providing the exact change at which a test started failing, instead of a range of suspect changes or doing a lengthy binary-search for the offending change. With such a huge, fast-moving codebase, it is possible for teams to get stuck spending a lot of time just keeping their build ‘green’. Release frequency varies from multiple times per day to once every few weeks, depending on the product team. The code base receives 20+ code changes per minute and 50% of the files change every month ! Each product is developed and released from ‘head’ relying on automated tests verifying the product behavior. Software development at Google is big and fast. If something breaks, finding and backing out the bad change is a tedious and error prone task for development teams.

As more code is added, each clean run takes much longer and more changes gets crammed into a single run. As a codebase grows over time, the effectiveness of such a system decreases. This works great while the codebase is small, code flux is reasonable and tests are fast.

Google test speed