How Google Tests Software

Google SWEs are feature developers. Google SETs are test developers. Google TEs are user developers.

Every project at Google has a primary design doc. It is a living document, which means that it evolves alongside the project it describes. In its earliest form, a design doc describes the project’s objective, background, proposed team members, and proposed designs. During the early phase, the team works together to fill in the remaining relevant se

Google tries hard to develop only products that users will find compelling and to get new features out to users as early as possible so they might benefit from them. Plus, we avoid over-investing in features no user wants because we learn this early.

Small tests are of short duration, usually running in seconds or less. They are most likely written by a SWE, less often by an SET, and hardly ever by TEs.

if a SWE has to modify a function and that modification breaks an existing test or requires a new one, they must author that test.

The question a medium test attempts to answer is, “Does a set of near neighbor functions interoperate with each other the way they are supposed to?”

The question a large test attempts to answer is, “Does the product operate the way a user would expect and produce the desired results?”

Instead of distinguishing between code, integration, and system testing, Google uses the language of small, medium, and large tests

Reuse is rewarded far more than complexity or cleverness.