Improving Test Infrastructure for Legacy System Refactoring: Insights from Google Test Engineers

Automated testing is a crucial component of continuous software delivery, and when teams must maintain numerous legacy systems or upgrade them, effective testing methods become essential; this article translates and organizes the approaches used by Google test engineers.

Automating manual validation of product releases to free developers for impactful issues.

Designing automated tracking of Android battery usage for immediate feedback.

Quantifying billion‑scale data products to compare new dataset quality against production.

Building test suites that verify user‑facing content meets quality standards.

Reviewing design docs and advising on testable implementations.

Investigating user‑submitted stack traces and locating code owners for upgrades.

Collaborating to pinpoint root causes of production failures and adding targeted tests.

Organizing task forces to share accessibility‑testing best practices across the company.

The focus then shifts to a major responsibility: building and improving test infrastructure to make engineers more efficient, illustrated through a scenario of replacing an old system with a new one while keeping the legacy system operational.

Two primary problems were identified: tight coupling and insufficient abstraction made unit testing difficult, forcing extensive end‑to‑end tests; and the lack of a mechanism to create and inject mock services meant tests had to start many external servers, creating fragile and heavyweight test suites.

Several solutions were explored: breaking large tests into smaller, focused ones (unfeasible without massive refactoring), attempting large tests with mocked non‑test functionality (still cumbersome due to constantly changing dependencies), and finally a third approach—strengthening small test cases by using RPC stubs and a mock framework such as Mockito to simulate external services.

The new model runs only the client, performs a few RPC calls, and verifies that dependent services behave correctly; this approach works for any RPC interaction, allowing reliable integration testing with compact test cases that reflect real behavior.

Adoption was rapid: engineers migrated existing tests to the new framework over several months, achieving comparable defect detection, reducing test runtime from ~30 minutes to ~3 minutes, and attaining 0 % client‑test failures; the tests can be run and debugged directly in an IDE, reserving full end‑to‑end runs for configuration checks.

Overall, building and refining test infrastructure empowers engineers to work more efficiently; the project spanned requirement gathering, prototype development, implementation, and continuous improvement, culminating in a tool widely used across the team.

For the original English article, see the links provided at the end of the source.