Fast Tests

Fast is not “tests should be quick”; it is the precondition for the tests being run at all. A suite nobody runs protects nothing. Eight independent authorities converge on it, from the FIRST acronym (2008) to Google’s SWE book (2020), with thresholds like hundreds of unit tests per second (Shore), a thousand tests per second per core (Bazuzi), and about ten minutes for the full suite (Fowler).

Minimal Data and parallel execution are the usual levers. Speed also pulls against Behavioral: tests that resemble real usage are slower, one of the trade-offs among the properties. Part of Test Desiderata.

Measuring: per-test wall clock with a CI gate (roughly 0.5 to 1s), and a suite wall-clock trend judged against Fowler’s ten-minute build.

Sources

• FIRST acronym (Fast, Independent, Repeatable, Self-validating, Timely), by Tim Ottinger, 2008 (popularized by Robert C. Martin in Clean Code, 2008).
• James Shore, Test-Driven Development (The Art of Agile Development, 1st ed.): “Unit tests, which run at a rate of hundreds per second”. (The 2nd-edition chapter says “hundreds or thousands per second”, but its free excerpt is truncated before that line.)
• Jay Bazuzi, Characteristics of Ideal Tests: a thousand test cases per second per core.
• Martin Fowler, Continuous Integration: the ten-minute build.
• Software Engineering at Google, ch. 12.