These three go together, and I’d read them in this order. Sebastian Bergmann, the creator of PHPUnit, builds a single argument across all three: test suite speed used to be a developer-experience problem, and it just became a security problem too.
-
Turbo-Charging Your PHPUnit Suite: A team of eight developers running a ten-minute suite twenty times a day collectively loses more than 26 hours to waiting. Bergmann’s four-tier fix starts with free configuration changes such as removing unnecessary process isolation and running
--order-by=defects. Test design comes next, especially “unit tests” that quietly hit a real database, followed by parallelization and infrastructure. His priority order is clear: fix test design before buying more hardware. -
Speed as a Security Feature: Security researchers now use LLM agents as tireless junior reviewers that form a vulnerability hypothesis, then try to prove it with a failing test. Suite speed taxes a human reviewer, but it sets a hard ceiling for an agent working through dozens of hypotheses per hour. Slow hypotheses may be dropped without leaving a record. Keeping a suite fast and partitionable therefore improves the depth of automated security review.
-
What Your Test Run Already Knows:
otr-reportputs the first two articles into practice by reading PHPUnit’s Open Test Reporting logfile. It identifies true outliers instead of merely listing the slowest tests in a uniformly slow suite; the--above-meanflag is the option I want most. It can also show runtime trends over several months and produce HTML reports with TestDox names for readers who do not use PHP.