Test Suite Runtime Calculator

Work out test suite runtime instantly with clear inputs, formula shown and shareable results.

About Test Suite Runtime Calculator

Suite runtime is dominated by the slow layers, not the numerous ones. Four thousand unit tests at 12 ms run in under a minute, while 380 integration tests at 850 ms each take over five. That asymmetry is the whole argument for the test pyramid: push assertions down to the fastest layer that can still catch the defect.

Formula

Suite runtime

total = unit count x unit duration + integration count x integration duration

Worked example

With the default values below, Test Suite Runtime Calculator returns Total suite runtime of 373.4. Change any input above and every figure here is recalculated in your browser.

Inputs used

Unit testsminimum 0: 4,200
Average unit test durationminimum 0.1 ms: 12 ms
Integration testsminimum 0: 380
Average integration test durationminimum 0.1 ms: 850 ms

Results

Total suite runtime: 373.4 s
Unit test time: 50.4 s
Integration test time: 323.0 s
Share spent on integration tests: 86.5%

Step by step

1Values used
2Suite runtime
3Total suite runtime= 373.4 s
4Unit test time= 50.4 s
5Integration test time= 323.0 s
6Share spent on integration tests= 86.5

Assumptions and limits

The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

Why are integration tests so much slower?

They pay real I/O: process startup, database connections, network calls and fixture setup. Each of those costs orders of magnitude more than an in-process assertion.

How can integration time be cut without losing coverage?

Share expensive fixtures across tests, run against in-memory or containerised dependencies, and reserve full end-to-end tests for a small set of critical journeys.