Test suite duration is treated as an inconvenience, filed alongside slow builds and awkward tooling. It is actually one of the more powerful forces shaping how a team writes software, and it works almost entirely through incentives rather than through time.
It changes the size of a change
When verification is cheap, people verify constantly and changes stay small. When it costs forty minutes, people batch work to amortise the wait. Larger changes are harder to review, harder to debug when they fail, and riskier to deploy.
So a slow suite does not merely delay feedback. It systematically increases the size of the thing being fed back on, which compounds the delay.
It moves failures away from their cause
The cost of a defect scales with the distance between writing it and finding it. Caught while the code is still in your head, it is a two-minute fix. Caught a day later, you are reconstructing your own reasoning. Caught in production, it is an incident.
Slow tests push every failure one step further down that ladder, because people stop running them locally and start discovering failures in CI.
It erodes trust, and trust is the whole point
Long suites accumulate flaky tests, because a test that fails one run in fifty is annoying to fix and easy to re-run. Once re-running becomes normal, a real failure looks exactly like a flake, and the suite has stopped functioning as a signal.
A fast, reliable suite of a thousand tests is worth considerably more than a slow, flaky suite of ten thousand.
Where the time usually is
Almost always the database and the network. Tests that hit real infrastructure for logic that does not need it, fixtures rebuilt per test rather than per suite, and end-to-end tests written for cases a unit test would cover in milliseconds.
Profile before optimising. A small minority of tests typically accounts for the majority of the duration, and the shape of that distribution tells you exactly where to work.
Set a budget and defend it
Pick a target — ten minutes for the full suite, under a minute for the unit layer — and treat exceeding it as a failure worth fixing, not as a fact of life. Without a budget, duration only ever grows, because every individual test is a reasonable addition.
Test speed is a proxy for how quickly a team can safely change its own software, which makes it one of the few engineering metrics worth watching directly.