How Google Tests Software

Reuse is rewarded far more than complexity or cleverness.

importance of the code and the care that engineers take when modifying it.

relatively low numbers of Google SETs isn’t because Google has created a magic formula for productivity, but more of a result of adapting our engineering practice around the reality that the SET skill set is hard to find.

“quality is not important until the software is important.”

Google takes code reviews seriously, and, especially with common code, developers must have all their code reviewed by someone with a “readability” in the relevant programming language.

Here’s the overall flow: 1. Write a class or set of functions for a service in one or more source files and make sure all the code compiles. 2. Identify a library build target for this new service. 3. Write a unit test that imports the library, mocks out its nontrivial dependencies, and executes the most interesting code paths with the most interes

Focusing on quality before a product concept is fully baked and determined to be feasible is an exercise in misplaced priorities. Many of the early prototypes that we have seen come from Google 20 percent efforts end up being redesigned to the point that little of the original code even exists by the time a version is ready for dogfood or beta. Cle

Of course, there is risk in the opposite direction too. If a product goes too long without testing involvement, it can be difficult to undo a series of design decisions that reduce testability to the point that automation is too hard and resulting test tools too brittle.

In other words, both SWEs and SETs answer coding questions. SETs are expected to nail a set of testing questions as well.