Test execution time
The wall-clock time to run your test suite — a key factor in whether engineers actually use the suite before pushing.
// Formula
// About this metric
Test execution time measures how long it takes to run a test suite from start to finish. It directly affects whether engineers run tests locally before pushing, whether CI/CD pipelines are fast enough to catch regressions before merge, and how many times per day you can iterate on a problem.
The metric is fundamentally contextual: the right target depends entirely on what the suite does. A unit test suite should complete in seconds; integration tests in minutes; full E2E regression suites in under 30 minutes. A universal benchmark would be misleading because a 10-minute run for a pure unit suite is slow while a 10-minute run for a full E2E suite is outstanding.
The most important number is not the absolute duration but whether engineers actually run the suite. A test suite that takes 25 minutes to run will be skipped. One that takes 90 seconds will be run on every commit. Optimisation investments should be guided by usage data, not arbitrary targets.
Parallelisation is the primary tool for reducing execution time without removing tests: distribute tests across agents or threads, run unit and integration tests separately in CI, and run the fastest tests first to catch regressions early. Sharding large suites across multiple CI runners can reduce wall-clock time by an order of magnitude.
// Calculator
🧮 Calculator
// Benchmark
// When this is healthy
For unit tests: under 30 seconds total per run for fast feedback. For integration tests: under 10 minutes. For full E2E: under 30 minutes. The number that matters most is whether engineers actually run the suite before pushing.
// Why no numeric benchmark
Optimal execution time depends entirely on suite scope (unit vs E2E), parallelisation strategy, and team workflow. A universal benchmark would mislead more than it'd help.
// When to use this metric
Track execution time when it is affecting feedback loop speed — either engineers are skipping local runs, or CI pipelines are becoming a bottleneck. Optimise aggressively when time exceeds the "tolerable wait" threshold for your workflow.
Measure separately for unit, integration, and E2E suites. Mixing all three into a single number obscures where optimisation effort should go.
// Common pitfall
Teams that optimise for execution time by deleting slow tests may improve their pipeline speed while quietly degrading their regression coverage. Before removing a slow test to improve execution time, verify that its coverage is redundant — not that it's merely inconvenient. A 2-minute test that catches a real class of regression is worth keeping.