Google and Microsoft Automated Test Case Classification: S/M/L and L0–L3 Levels

With the rise of DevOps, two common questions emerge: what qualifies as a unit test and who should write them. Major tech companies have already addressed these issues.

Google: Automated Test Cases S/M/L

Google’s early testing culture treated engineer‑driven tests as optional, relying on “smart people” to write good code. By 2005, poor service quality forced the Google Web Server team to mandate automated tests and continuous integration, even assigning a “Build Cop” to enforce build health. This effort halved emergency fixes and grew to tens of thousands of automated tests, enabling daily releases with few user‑visible defects.

Google identified two dimensions for each automated test case: resource consumption (memory, processes, time) and verification scope (size of the code path exercised). Tests are classified as small, medium, or large based on the resources required by the test infrastructure. Small tests run in a single process, medium tests on a single machine, and large tests anywhere needed.

Google emphasizes speed and determinism over the traditional unit‑vs‑integration distinction, keeping large end‑to‑end tests separate from the regular development workflow.

Microsoft: Automated Test Case Levels L0–L3

In the pre‑DevOps era, Microsoft employed two dedicated testing roles: Software Design Engineer Test (SDET) for building automation infrastructure and Software Test Engineer (STE) for running automated and manual tests, often at a 1:1 developer‑tester ratio.

Microsoft later introduced a test level taxonomy:

L0/L1 – Unit tests: L0 are fast, in‑memory tests with no external dependencies; L1 may require binary integration packages, databases, or file‑system access.

L2/L3 – Functional tests: L2 validates deployable services with some dependencies stubbed; L3 are restricted integration tests executed in production‑like environments requiring full product deployment.

After a two‑and‑a‑half‑year effort, Microsoft’s VSTS team shifted from large system‑test dominance to a focus on L0 tests, eliminating dedicated SDET/STE roles and moving test ownership to developers.

Both companies illustrate how systematic test classification and automation can improve debugging, confidence in change, documentation, review simplicity, thoughtful design, and rapid high‑quality releases.